Quality review system with metadata collection

ABSTRACT

A quality review system may be used to analyze the operation of manufacturing processes within a plant based on data collected by various data sources in the plant, such as batch executive applications, to automatically detect, store, and display exceptions within those processes for use by a quality review engineer to determine if the process operation meets certain quality standards. The quality review system includes a configuration application that enables a user to create one or more exception rules, an exception engine that analyses process data using the rules to detect one or more exceptions within the process, and a review application that enables quality review personnel to review each determined exception for resolution purposes. Moreover, the quality review system collects metadata about the process plant for or after detecting an exception and stores the metadata along with an exception record for use by a reviewer. This system thus provides the reviewer with contextual information regarding the detected exception which, in turn, enables the reviewer to better understand and process the exception.

RELATED APPLICATIONS

This application is a continuation application that claims the benefitof priority from U.S. patent application Ser. No. 17/048,180 entitled“Quality Review Management System” filed Oct. 16, 2020, which is a USNational Phase of International Application Serial No. PCT/US19/28138,entitled “Quality Review Management System,” filed Apr. 18, 2019, whichclaims the benefit under 35 U.S.C. § 119(e) of U.S. Provisional PatentApplication Ser. No. 62/659,325, entitled “Quality Review ManagementSystem,” filed Apr. 18, 2018, the entire disclosure of which are herebyexpressly incorporated by reference herein.

FIELD OF TECHNOLOGY

The present invention relates generally to manufacturing managementsystems and, more particularly, to quality review management systemsthat enable advanced quality review procedures with respect tooperations of plants, processes, batches, and other activitiesimplemented in manufacturing plants.

DESCRIPTION OF THE RELATED ART

Manufacturing plants, such as process plants, typically produce one ormore products from a set of raw or pre-processed materials. In manycases, the produced product must be of a certain quality or must bemanufactured according to one of various different quality standards tomeet customer requirements, industry standards, the Food and DrugAdministration (FDA) requirements, safety requirements, labelingrequirements, etc. In many cases, separate quality review personnel aretasked with implementing various activities associated with assuringthat the produced product meets a set of pre-established standards orrequirements or was manufactured to a particular standard. Suchactivities may include reviewing the states or the values of variousparameters of the manufacturing equipment, materials, or processes usedto make the product to assure appropriate manufacturing steps wereimplemented, that the product was made under various desirableconditions, such as within certain temperature ranges, PH ranges,pressure ranges, etc. Of course, these quality review tasks aredependent on the type of product being made, the manufacturing processor equipment used to make the product, the quality standards that arebeing met, etc. As such, quality review is a highly specialized activityin many manufacturing environments, requiring intimate knowledge of theproduct, the manufacturing process, and the quality standards.

As an example, batch processes are typically used to make various typesof food or drug products that are highly regulated by various food anddrug industries or organizations, such as the FDA. The specific processsteps and conditions under which these products are made are typicallyset or regulated in some manner to assure the safety of the producedproduct or to assure that the product meets certain labeling criteria(e.g., that the product is gluten free, Kosher, etc.) As an example, theprocess steps used to make a product may require or mandate that certainprocess steps be implemented on the raw or intermediate materials duringthe manufacturing process, that certain cleaning procedures beimplemented on the process equipment within or between manufacturingsteps of the manufacturing process, that various parameters, such astemperatures, pressures, PH balances, etc., be maintained within certainranges or above or below certain thresholds throughout the process orduring critical times of the process, etc. As a result, in many cases,the product manufacturer needs to collect and store data regarding theactual operation of the manufacturing equipment during the manufacturingprocess to be able to prove to a regulating authority or customer thatthe produced product meets the appropriate quality standards, forexample, that the product was produced according to or underpre-established procedures or conditions.

Process plants that are used to make various types of products, such asfood, petroleum, drug, etc. products are generally complex and highlyautomated. In particular, industrial process plants, such as those usedin chemical, petroleum refining, food manufacturing, drug manufacturing,or other processes, generally include one or more process controlnetworks having centralized or distributed process controllerscommunicatively coupled to one or more field devices which may be, forexample, valve positioners, switches, sensors (such as temperature,pressure and flow rate sensors), tanks, mixers, heaters, etc. Thesefield devices or field equipment may perform physical control functionswithin the process plant (such as opening or closing a valve, stirringor mixing materials within a tank, heating a container, etc.), may takemeasurements within the process plant for use in controlling theoperation of the process plant, or may perform any other desiredfunction within the process plant. Process controllers have historicallybeen connected to field devices via one or more analog signal lines orbuses which may carry, for example, 4-20 mA (milliamp) signals to andfrom the field devices. In the past couple of decades or so, however,the process control industry has developed a number of standard, open,digital or combined digital and analog communication protocols such asthe Foundation™ FIELDBUS (hereinafter “Fieldbus”), HART®, PROFIBUS®,WORLDFIP®, Device-Net® and CAN protocols which can be used to implementcommunications between process controllers and field devices. Generallyspeaking, a process controller receives signals indicative ofmeasurements made by one or more field devices and/or other informationpertaining to the field devices, uses this information to implement atypically complex control routine, and generates control signals whichare sent via the signal lines or buses to the field devices to therebycontrol the operation of the process plant.

Certain types of process control networks, such as those used in batchprocesses, typically include multiple sets of replicated equipment, witheach set of equipment being designed to have the same or similarhardware that performs essentially the same basic function within theprocess plant. Thus, for example, a cookie manufacturing plant may havemultiple sets of mixing equipment, multiple sets of baking equipment,and multiple sets of packaging equipment, with some or all of theindividual mixing equipment being capable of operating in parallel andof being connected to operate in series with some or all of the bakingequipment and the packaging equipment. In such a system, it is typicalto use the same general control algorithm or routine to control theoperation of any particular set of replicated equipment to make the sameproduct (as defined by a specific batch recipe). Thus, any particularbatch run, which is defined by an order, that specifies or identifies aparticular amount of a particular type of product being manufactured,may be implemented on any combination of various different sets ofequipment in the plant. Typically, each such batch run or order includesa specific control procedure that performs a number of different stepsor stages in sequence to implement a recipe, finishing the first stagebefore beginning the second stage and so on. Thus, in the cookiemanufacturing plant described above, a batch run or order may implementa batch control procedure to control the mixing equipment, may thenimplement a procedure to run the baking equipment on the product made bythe mixing equipment and may then execute a third procedure thatcontrols the packaging equipment to package the product produced by thebaking equipment, each step of which takes a finite amount of time. Inmany cases, a batch run also implements procedures to clean, empty,fill, etc. tanks or other containers or equipment in the plant as partof each order. Of course, each order may have a different set ofspecifications, which may require a different set of raw materials, adifferent recipe, different flow or batch procedures to be implementedon the raw materials, and even different quality standards.

One batch control standard that has been promulgated by theInternational Society for Measurement and Control, an internationalorganization concerned with issues of process control, is entitled BatchControl Part 1: Models and Terminology, and is often referred to as theISA S88.01-1995 standard, or one of its updates (referred to herein asthe “S88 standard”). The S88 standard defines models of equipments andprocedures for use in automated batch processes, and defines certainterminology for use in referring to those models and their elements. Forexample, the S88 standard defines a “batch process” as a process thatleads to the production of finite quantities of material by subjectingquantities of input materials to an ordered set of processing activitiesover a finite period of time using one or more pieces of equipment. Asanother example, a “batch” is defined by the S88 standard as thematerial that is being produced or has been produced by a singleexecution of a batch process.

As noted above, batch processing equipment (e.g., controllable elementssuch as valves, heaters, mixers, etc.) is operated during a batchprocess or a batch run according to pre-defined procedures to make abatch. All such batch processing equipment is referred to synonymouslyherein as equipment, equipment modules, processing equipment, and/orphysical elements. The procedures to operate such physical elements areoften referred to by the S88 standard as the “procedural model.”According to the S88 standard, the procedural model is structured as ahierarchical ranking of procedures, with the highest level encompassingeach of the lower levels, the next highest level encompassing each ofthe levels below it, and so on. The levels of the S88 procedural modelof particular interest include, in descending order, “procedures,” “unitprocedures,” “operations,” and “phases.” The terms “procedural element”or batch sub-procedures are used herein to refer to any embodiment orimplementation of any of these levels of the S88 procedural model aswell as to any other hierarchical definition of a set of batchprocedures.

As indicated above, the highest-level S88 procedural element of interestis referred to as a procedure, which is made up of one or more unitprocedures. Each unit procedure is or can be in turn made up of one ormore operations, which are each in turn made up of one or more phases.Moreover, the S88 procedural model does not preclude the definition anduse of other hierarchical levels in particular applications. Rather, theS88 standard and the procedural elements referred to herein are intendedto provide a broad, standardized model for describing the proceduresfollowed in automated batch-process control, and these elements are notlimited to the four procedural elements defined by the S88 standard.

The different procedural elements of a batch are generally implementedin practice as computer programs that are executed by and withindata-processing devices, including personal computers, workstations, andprogrammable controllers. Execution of a typical procedural elementresults in an electrical or optical output from the data-processingdevice that can be used to control a physical element, typically byconnecting an output of the data-processing device to the physicalelement directly, or indirectly over a local-area or wide-area network.A procedural element performs an assigned or associated task by invoking“basic control” with respect to at least one physical element. This typeof control is typically dedicated to establishing and maintaining aspecific desired state of the physical element. Basic control wouldinclude, for example, starting or maintaining a flow of material in astorage bin element, heating the starting materials in a polyvinylchloride reactor element, etc. In practice, the lower levels of theprocedural model (namely phases) perform the actual communications withthe actual physical elements, thereby invoking or performing basiccontrol. The higher levels of the procedural model are essentiallyabstractions to improve the organization and the structure of theprocedural model, as well as the physical model.

Moreover, many batch systems use a batch executive to control theoperation of one or more batches in a plant according to the proceduralmodel being used. The batch executive may be or use a state machinemodel as a logical construct to describe the state of a batch process oractivity. The state machine model describes or defines a number ofprocess states, together with actions that cause transitions betweenthose states. A state machine model of a process is said to be in aparticular state due to an earlier transition into that state. When aparticular event occurs or a particular status is sensed, the statemachine model makes a transition to another state corresponding to theparticular event or sensed status. State machine models are usefultechniques for defining and implementing the operation of proceduralelements of a batch process. In particular, a procedural element definedand implemented as a state machine initiates an action, for example,when its associated state machine makes a transition from an old stateto a new state.

Of course, the S88 standard permits the definition and implementation ofprocedural elements in accordance with a standard state machine model.While the S88 standard does not mandate this approach, this approach hasbeen broadly adopted in the process control industry to enable a higherdegree of interoperability among the products of various vendors. Onepresent commercial application of the S88 standard having proceduralelements defined and implemented according to a state machine model isthe DeltaV™ Batch product from Emerson Process Management. In DeltaV™Batch, a server program or a batch executive program runs on the dataprocessing device that executes the various procedural elements. Theserver or batch executive program (referred to as a “batch executive”)coordinates execution of procedural elements in accordance with one ormore state machine models so that procedures, corresponding unitprocedures, corresponding operations, and corresponding phases aresequenced through their respective steps by the server program. In anyevent, during the implementation of a particular batch run or aparticular batch process associated with an order, such as when a phaseis initiated by the server program, the phase communicates theinitiation request to the phase logic interface within a programmablecontroller. The programmable controller then executes the actual statelogic or control routine for the phase and provides the required processcontrol via communications to the process equipment.

As will be understood from the previous discussion regarding qualityreview of processes, it is desirable to gather data representative ofthe operation of a batch process, including historical events that makeup the processing of a batch run in order to be able to determine if thebatch run for an order operated or executed satisfactorily according tothe applicable quality standards. Such historical data may be useful notonly for quality review purposes, but for determining trends in qualitycontrol or for determining when equipment used in the batch process isin need of service. A number of types of data are potentially useful inreviewing the quality or progress of a batch process. One such source ofdata is continuous data generated by the various data points in thebatch process during the processing of the batch. A data point is asingle source of such continuous data that reflects some control valueor other status or measurement of the batch process. For example, aparticular level of a material flow or a temperature of a material asmeasured by a sensor might be such data points. A present setting of acontrol valve, the time at which a sample was taken, etc. may be otherdata points. Each such data point may have a continuous stream of datavalues sensed or controlled over time by the batch process applicationassociated therewith. The aggregation of all such continuous data,generated during processing of a batch, is often logged by a batchprocessing system and stored as part of a batch log file in a batchdatabase. These batch log records usually include a timestamp and apresent value along with other identifying information for the datapoint such as a tag to identify the source of the data.

Another type of data useful in reviewing the quality or progress of abatch process is batch state and event information, which relates to orincludes information that describes the batch process in terms ofexecution of the procedural model (e.g., the state of the batch process,transitions between states of the batch model, etc.). For example, batchevents that describe the start and end time of a particular phase or aparticular operation, unit procedure or procedure of the proceduralmodel constitute event information. Event information also includesprocess events, including information generated by the physical elementsof the batch process or by an operator. In particular each equipmentmodule, cell, etc. of a process may generate process events thatindicate one or more specific activities in the starting, stopping, orrunning of a particular phase (i.e., performing specific basic controlactions). Alarm and event conditions recognized by the process equipmentare further examples of process events. Process events may also includeinformation regarding operator changes to the batch process made duringoperation of the batch process.

Still further, many batch process systems utilize an operator interfaceprogram, operated on a dedicated operator interface device, such as aworkstation, to enable an operator to view the current state of a batchrun, to take manual steps within the batch run, such as setting variousparameters manually, selecting process equipment for execution ofvarious batch procedures, operations, phases, etc., making notesregarding unexpected activities or conditions during a batch run ororder, etc. One such operator interface program is known as a workflowprogram (such as the Syncade Workflow program provided by EmersonAutomation Solutions) which intercepts or receives various informationfrom the batch executive or process equipment (e.g., processcontrollers) used to implement a batch run for each order beingprocessed. The workflow programs may subscribe to various types of datafrom the batch executive or process control system and may present thisdata to the operator to enable the operator to view the current state ofthe batch run, to view transitions between states in the batch model, tomake changes in the batch run, to manually stop and start various batchprocedures, operations, phases, or equipment, and to deal with problemsor unexpected events that arise within a batch run. For example, in manycases, unexpected errors or problems may occur within a batch run, suchas batch equipment or raw materials being unexpectedly unavailable,process parameters being out of an expected or desired range, etc. Inthese cases, the workflow program enables the operator to make andimplement decisions as to how to proceed, such as skipping a batch stepor procedure, specifying other equipment or materials to use, changingprocess plant variables, setpoints, or parameters to deal with alarms orevents in the process, etc. Generally speaking, the workflow programalso stores data indicative of operator actions within the batch logfile, along with the raw batch data being stored in the batch log file.In many cases, the workflow program also enables the operator to makenotes or to store explanations of what was happening in the batch at thetime of the action, why the operator took the particular action, etc.,and these notes are stored in the batch log file as well.

In any event, in many industries, after a batch run has occurred and aproduct or order has been completed, a quality engineer or other qualitypersonnel (referred to generally herein as quality engineers) mustverify that the product meets the appropriate quality standards. Toperform this review, the quality engineer accesses and views the batchlog file for the batch run of an order (typically on an order by orderbasis) to assure that the batch run completed according to or withinexpected parameters, workflows and ranges. Generally, to perform thisreview, the quality engineer must scroll through the raw data in thebatch data file looking for “exceptions” to the expected operation ofthe batch run. The term “exception” is generally used herein to indicatea deviation from an expected procedure, process, step, workflow, range,value, etc. within a manufacturing process or plant. Exceptions may be,for example, one or more process variables or parameters being out of anexpected or desired range, or above or below expected or desiredthresholds, a batch procedure, operation or phase being skipped orperformed out an expected sequence, a batch procedure, operation orphase stopping or starting at unexpected times, or taking longer orshorter than an expected operation time, different or unexpectedmaterials being used in a batch procedure, additional steps or actionsbeing implemented by the operator during the batch run, changes to arecipe, notes generated by the operator during a batch run, alarms andevents that occurred during a batch run, etc.

In any event, the quality engineer must identify the exceptions based onthe raw data stored in the batch log file, must then determine an effector severity of each such exception, and what if any procedures to taketo handle or “close” the exception. For example, in many cases,exceptions may only represent minimal or unimportant deviations in theexpected batch run that do not result in any or in any significantquality reduction of the produced product according to the qualitystandards being implemented. In other cases, exceptions may need to bedocumented for later review by authorized agencies or by the customer,but may not be severe enough in their effect to result in a significantreduction of the quality of the product. In still other cases, theexception may be significant or important enough that the product needsto be put through one or more additional procedures to assure thedesired quality, or to require that one or more tests be performed onthe product to assure the quality of the product. In still other cases,the quality engineer may determine that, based on the specifics of theexception, the product needs to be scrapped, or that the product needsto be marketed under a lower quality or labeling standard.

The process of looking through a batch log file for exceptions is highlytedious and fraught with problems. In particular, most of the datawithin the batch log file is not indicative of an exception, and so thequality engineer spends a significant amount (usually most) of thereview time looking at data that is not actually associated with anyexception. Still further, the quality engineer must keep in mind all ofthe conditions that lead to an exception, including for example, desiredvalues or ranges of important process variables, the expected order ofbatch procedures, the expected stop and start times for variousdifferent batch procedures, etc. While the existence of batch processalarms and alerts or notes from the operator that are stored in thebatch log file may indicate the existence of an exception, this is notalways the case and, of course, not every exception that occurs may bedocumented with an operator note or may rise to a level that causes anassociated alarm or alert to be generated in the control system. As willbe understood, the actual exceptions that are determined are thusdependent on the skill of the particular quality engineer performing thereview and the particular quality standards being met.

Still further, when the quality engineer finds an exception (e.g., aprocess value being out of range, etc.), the engineer must usuallydetermine the context of the batch at the time of the exception in orderto determine the severity of the exception, and how to best respond toor handle the exception. This process may involve obtaining additionaldata about the state of the batch run or batch procedure at the time ofthe exception, values of other process variables at the time of theexception, determining if alarms or events were generated in the same orother process equipment at the time of the exception, etc. This processthen generally requires the quality engineer to use other available dataaccess systems to determine the additional process state information atthe time of the exception. This data acquisition activity can be timeconsuming and requires additional know-how on the part of the batchquality engineer.

For example, to view the operation of a batch from a batch log file, itis not a simple task to obtain a snapshot of the batch process at aparticular time and display that data to a quality engineer, as thebatch process has various different procedural elements, which may berun on different equipment within the plant at different times, usingdifferent setpoints, settings, etc. Instead, to view a batch run, thequality engineer may need to review and analyze data from the batch atvarious times related to the procedural events of the batch (i.e., thesub-procedures and sub-processes associated with the batch) to therebybe able to understand the operation of the batch run at the time of theexception. While various batch data is typically automatically collectedand stored during operating of the batch run, these different types ofdata are generally collected by different subsystems and, in fact, maybe stored in different databases. This fact makes it difficult for thequality engineer to have a comprehensive view of any particular batchprocess. For example, data such as alarm data and sensor measurementdata which is obtained from actual field devices such as sensors,valves, etc. within the batch process are typically stored in a datahistorian as time-stamped data and are available from the data historiangenerally based on the time at which the data was collected. However, adifferent database, such as one associated with a batch executiveroutine, may store the start and end times of a batch run and thevarious different sub-procedures or procedural elements within the batchrun. This all makes it more difficult for the quality engineer tounderstand the context of an exception without significant data lookupin various other subsystems of the batch process.

SUMMARY

A quality review management system (also referred to as a review byexception (RBE) system) may be used to analyze the operation of one ormore manufacturing processes as collected by various other process plantdata sources, such as data sources within a process control system,workflow applications, batch process operator applications, batchexecutive applications, etc. The quality review management systemautomatically detects exceptions within those processes and stores datapertaining to the detected exceptions in an organized and easilyreviewable manner. The quality review management system also enables aquality review manager or engineer to review and handle (resolve)exceptions associated with the process in an easy to use interface.

More particularly, the quality review management system includes aconfiguration system that enables a user to create and store rules, in arules database, that may be used to automatically identify one or moreexceptions within a process, such as a batch process. The rules mayidentify a set of conditions that must be met to identify an exception,the severity of the identified exception, information about theexception, processes or procedures used to handle, resolve, or close theexception, process data or other data to be stored as part of anexception record to assist a quality review engineer in understandingand resolving the exception, etc. The quality review management systemalso includes an exception engine that processes data within a datamessage, such as a data message provided periodically by a data source,like a plant or process control system, a batch executive, an operatorworkflow application, etc., using the rules in the rules database todetermine if the data within the data message includes an exception, asdefined by any of the rules. The exception engine, upon identifying anexception, may then store information about the exception as anexception record, such as a name, a type, a severity of, procedures orsteps to take to resolve or handle the exception, and process datapertaining to the operation of the process in which the exceptionoccurred at the time that the exception occurred. The exception enginemay store this and/or other data for each identified exception as anexception record in an exception file (e.g., an exception database) foreach order. Moreover, the exception engine may operate in real timeduring operation of the process implementing an order to create anexception file or database for the order and may provide live feedbackto a process operator that an exception has occurred or is about tooccur.

Thus, in one example, the quality review system provides a configurationenvironment to enable a user to create configurable exception rules toexecute in an exception engine to define or detect exceptions. Theconfiguration environment may store a set of rule templates that mayprocess various types of input data to detect an exception. In theconfiguration environment, a user may select one of the templates, maydefine inputs/outputs, and may define a possible expression to beanalyzed for a set of data. When the data flows through the engine, itwill analyze the data against the configured rules; if any rule'scriteria is met, an exception is created. The exception may then beimmediately checked. Typical known review by exception products requirethe exception software provider to hard code the exceptions defined forthe system into the product, and thus require a software or systemupdate to create new exceptions. These updates take time for the user toget and install, and do not enable users to customize their own systems.

The quality review management system also includes a review interfacethat enables a quality review engineer or other personnel to review anddeal with exceptions as identified by the exception engine and as storedas exception records in an exception database for an order. Inparticular, the review interface may access an exception database for aparticular order and may present information regarding each identifiedexception to the quality review engineer in an organized and easy tounderstand manner. The review interface may provide the quality reviewengineer with data stored for each exception record, such as a name, atype, and a severity identification for each exception record. Thereview interface may provide the reviewer with stored information aboutthe exception as identified by the exception record, the type ofexception, etc. as well as with data pertaining to various process orbatch variables, states, procedures, etc. that existed at the time thatthe exception occurred. This information will enable the reviewer toeasily understand the exception, the context of the process at the timethat the exception occurred and the severity of the exception. Stillfurther, the review interface may enable the reviewer to take variousactions with respect to each exception. Such actions may includeacknowledging the exception, signing off on or closing the exception,annotating the exception with further information such as why theexception can be ignored or signed off, sending the exception record toanother person, etc. The review interface may also provide the reviewerwith suggested actions, and may in some cases enforce particularactions, to be taken with respect to resolving or closing the exception.Such actions may include, for example, requiring sign-off by a certainnumber or type of people (e.g., the reviewer alone, the reviewer and amanager, two reviewers, etc.) Other actions may include requiringcertain information to be provided from the reviewer, such asannotations, process information, etc. that will be stored with theexception record for later use by the customer, the quality reviewingauthorities, etc.

The review interface may store the processed exception records in adatabase or file and may enable the reviewer to scroll through theexception records in the exception database to determine if and when allof the exception records for an order have been processed or closed, thestatus of the review (e.g., how many unprocessed exceptions exist in theexception record database), statistical data pertaining to the exceptionrecords (e.g., how may exceptions of each type or severity exist in thefile, etc.) The review interface may also enable the reviewer to groupexception records in various manners, such as by type, severity,processing status (e.g., unreviewed, reviewed but not closed, closed,etc.). Still further, the review interface may enable the reviewer totake one or more actions on an entire group of exception records, suchas closing all of the exception records in a group, annotating all ofthe exception records in a group, etc.

In this manner, the quality review management system may be set up(configured) and executed during the operation of a batch process orother process to automatically identify exceptions, as they occur withina process run, may notify a process operator that an exception hasoccurred or that an action taken by the process operator will result inan exception, and may store all determined exceptions for a particularprocess (e.g., a batch process) in an exception record database. Thequality review management system also enables a quality review engineerto quickly determine, view and deal with the exceptions within anexception database without needing to review a lot of raw data, as iscurrently necessary. Likewise, the quality review management system canenforce various rules in the exception handling or resolution process,such as assuring that exceptions of various different types orseverities are processed or dealt with in a particular manner, therebyproviding consistency in the quality review process.

Still further, the quality review management system may be implementedin a plug-in environment to enable the system to interface with and beused to analyze third party systems or applications for exceptions. Inone case, a plug-in may be created or configured to obtain certain datafrom a third party application or data source and may then pass thisdata to an exception engine for processing by one or more exceptionrules. As one example, the quality review management system may be usedto interface with event monitoring systems, such as those that use OPCinterfaces, to obtain and analyze data from third party process controlsystems or plants.

In one example, the plug-in modules are created to interface the RBEexception engine with external or third-party systems (e.g., controlsystems, OPC interfaces, maintenance systems, etc.), thereby enablingexceptions to be generated based wholly or in part based on data fromthird party or external software systems. Plug-ins may be created toaccess particular data within or from a third party or external systemand to pass this data to the RBE engine to analyze whether an exceptionshould be created or not. The plug-ins may be run in the third-partyserver, in the RBE server or in another server, and may or may notperform exception detection. Thus, the plug-ins can be simplethird-party system data gatherers, or may gather data and additionallyperform some exception processing, providing an exception orpre-processed exception data to the RBE engine.

Known review systems are currently unable to interface with or createexceptions based on data provided directly from external softwareprograms, like control systems, safety systems, maintenance systems,etc. Plug-ins make the RBE system much more robust in a complicatedprocess environment having multiple different software systems operatingduring runtime.

Still further, in one example, an RBE system may include a live viewcomponent that collects a set of metadata (which may be predefined when,for example, creating a plugin) when collecting the RBE input data (thatis, the process data used to define or generate an exception). Themetadata may be any other process or environment data and is collectedat the same time as the exception input data. This metadata is stored asa process snapshot associated with the accessed exception data. When theRBE system detects an exception based on the collected exception data,the RBE system also stores the metadata as part of the exception. TheRBE system additionally displays some or all of the metadata whenreporting the generated exception, thereby providing the user orreviewer with a live view into the process at the time that theexception arose within the process. This system provides the user with aquick view of various process states/values, etc. at the time of theexception, which enables the user the more quickly understand why theexception arose and the severity of the exception, thus enabling theuser to more quickly process the exception.

While known process review products provide a list of generatedexceptions to the user or reviewer, the reviewer must still analyze eachexception to determine whether the exception can be dismissed or must bedealt with in some other manner. However, generally speaking, thereviewer must go back to the process system in which the data that leadto the exception was collected to understand other things about theprocess at the time of the exception (e.g., was the process on-line oroff-line, the state of a batch at the time of the exception, etc.) Withthe live view feature, the user can be automatically provided with aprocess snapshot that will generally include the process data mostuseful to the reviewer in performing exception review, which means thatthe reviewer does not need to go back into other data collection systemsto get the information the user needs to perform exception review. Thisfeature also means that the reviewer does not generally need to be asfamiliar with the other process systems from which the data is collectedas the reviewer will not need to use those systems to access the processdata the reviewer needs

In another example, an RBE or quality review system includes an eventmonitor that may be tied to a third party or external system and thatgenerates and sends messages to the RBE system, which can then use thesemessages to perform exception processing or exception creation. In onecase, the event monitor may be tied to or coupled to an OPC alert andalarm monitoring interface, and may recognize when one or more alerts oralarms are passed to the OPC interface. At this time, the event monitorcreates and drops a message to the RBE system with the alert or alarminformation and potentially any other desired OPC collected data. TheRBE system may then analyze the messages to generate exceptions based onthe alarms and alerts. Typical review system do not analyze data fromthird party systems, and none of them are connected to the OPC alert andalarm interfaces that exist. As such, these systems are not able togenerate exceptions based on process alarms and alerts, for example.

Likewise, the quality review management system may use a new pagingalgorithm when presenting lists of exception records to a reviewer viaan electronic display or user interface. This paging algorithm, whichoperates in a manner that reduces or eliminates the presentation ofmissing records or duplicate records in the review process, stores oneor more anchors to track the actual records in the current display pageof records being provided in an interface display. The system then usesthe anchors for the page that is currently being displayed to determinethe starting position of the next set or records to display as part ofthe next page, which enables the paging system to operate appropriatelyeven as records are added to or are removed from the list of records tobe displayed during the review process.

In one example, the review system implements a new paging algorithm whenpresenting lists of generated exceptions to a reviewer. Generally, RBEsystems create/detect exceptions and store these exceptions as recordsin a structured database, such as an SQL database. Then, when presentingthe list of exceptions to a reviewer on a display screen (and there canbe a large number of exceptions or records), the RBE system searches thedatabase for all relevant exception records, downloads pages of links tothese records, and then presents records within portions of theretrieved pages in the order downloaded from the database as the userscrolls through the various pages of exception records. However, as thereviewer processes the exceptions and scrolls down the list ofexceptions as displayed on the user interface, the records may change inthe database, and thus the page data may become out of date. Inparticular, records may be added or may be deleted from the database. Inthis case, when the system attempts to present the records on a displayscreen, various records referred to in the pages may be missing, causingvisual data loss or duplication. In some cases, the user may miss arecord going from one page to the next due to the deletion of a recordon a particular recovered page. In other cases, the system may becomeconfused as to where to start a new display page based on missingrecords that were in the downloaded pages. The new system operatesdifferently, in that it downloads records presented on a display screenstarting from the last record displayed on the screen. That is, insteadof presenting a new display page associated with the original pages ofrecovered records, the system accesses the database for a set of recordsthat currently exist immediately after the last record on the displayedpage, thereby assuring that each time a new set of records is displayedon the screen, the first new record displayed is the record immediatelyfollowing the last record that was being displayed immediately beforethe time of the scroll.

This display system is more accurate as it assures that records are notdisplayed out of order or missed in the review process in which the useris scrolling down various pages of records over a long period of time.Moreover, the RBE system is more efficient as it only needs to accessthe database for the number of new records that will fit on a newdisplay page as the user is scrolling through records, while stillassuring that all of the relevant records are accessed as the userperforms the scrolling process.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a typical process or manufacturing plantincluding a process control network, a batch executive, and a work flowapplication that enables an operator to manage a batch process and storea batch log file for quality review.

FIG. 2 is a block diagram of a plant environment similar to FIG. 1 butincluding a quality review management system having a configurationapplication, an exception engine, and a quality review interfaceapplication for use in performing exception based detection and qualityreview within a plant environment.

FIG. 3 is an exemplary screen display created by the configurationapplication of the quality review management system of FIG. 2 to enablea user to create one or more exception rules for use by an exceptionengine.

FIG. 4 is a flow chart illustrating the operation of the exceptionengine of the quality review management system of FIG. 2 when analyzingdata from multiple data sources for exception processing.

FIG. 5 is an example screen display illustrating live feedback from thequality review management system to an operator of a batch processinforming the operator of the detection of an actual or potentialexception within the process in real time.

FIG. 6 is a diagram illustrating the operation of a quality reviewmanagement system implemented in a plug-in environment.

FIG. 7 depicts an example event monitoring system that uses a qualityreview management system in a continuous process environment to performmonitoring of third party applications and systems.

FIGS. 8A-8G depict exemplary screen displays created by a reviewinterface application or a configuration application of the qualityreview management system of FIG. 2 to enable a quality reviewer toperform various activities related to exception rule configuration andexception record viewing and handling.

FIGS. 9A and 9B are diagrams illustrating the operation of a typicalpaging technique used to provide lists of records to a user in, forexample, a web environment.

FIGS. 10A and 10B are diagrams illustrating the operation of a newpaging technique that may be implemented by the quality review interfaceapplication of FIG. 2 to reduce or eliminate duplicate or missingrecords when performing paging through a set of records.

DETAILED DESCRIPTION

By way of background, FIG. 1 illustrates a typical plant or processcontrol environment 10 in which typical or existing quality reviewmanagement actions are implemented. The plant environment 10 includes aprocess control network 20, which may include various process controldevices, such as controllers, field devices (e.g., valves, sensors,transmitters, tanks, mixers, etc.), I/O devices, etc., which arecommunicatively connected together and are all programmed to operate orimplement a manufacturing process of some nature, such as a batchprocess or a continuous process. Still further, the plant environment 10may include a batch executive 22 (implemented on a processor of acomputing device, such as a workstation or server) that may interfacewith the process control network 20 to cause the process control network20 or devices within the process control network 20 to take variousactions associated with a manufacturing process, such as implementingvarious orders or batch runs, including implementing different stages ofvarious batches, such as unit procedures, procedures, operations,phases, steps, etc., of batch processes associated with each order.Still further, both the process control network 20 and the batchexecutive 22 may be coupled to a further network 24, which may belocated in, for example, a business environment away from the plantfloor or manufacturing space. The network 24 may include acommunications backbone 25 that communicatively connects variousdevices, such as computer display devices or workstations 26 and 28,various databases 30, 31, and 32 and other computer devices, if sodesired, such as gateways to the internet or other communicationnetworks, servers, wireless or handheld devices, etc. (not shown in FIG.1). The devices 26, 28, 30, 31, and 32 may be communicatively connectedvia any desired physical communications network or backbone 25, such asan Ethernet network, an Internet or other local area network (LAN) orwide area network (WAN), etc. Likewise, the process control system 20and the batch executive 22 may be connected to the various devices anddatabases 26, 28, 30, 31, and 32 via the network backbone 25 directly orvia other intervening networks if so desired.

In this prior art system, a workflow application 40 may be stored in anoperator interface device (the workstation 26, for example), and theworkflow application 40 may be executed by a processor of theworkstation 26 to interface with the batch executive 22 as the batchexecutive 22 is controlling the process control network 20 to implementvarious orders or batch runs. The workflow application 40, which may be,for example, the Syncade Workflow application sold by Emerson ProcessManagement may operate to obtain and display data from the batchexecutive 22. This data may include ongoing batch status data, parameterdata, measurement data, progress data, batch procedural model statedata, etc., as acquired by the batch executive 22. This information ordata may include indications of the order being implemented, thematerials and processes associated with the order (e.g., the recipe andthe batch procedural model to be implemented), alarm and alert data fromthe batch executive 22 and/or the process control network 20, etc. Anyor all of this data may also be stored in a batch log file database 32as a batch log file 34, as is typical for batch executive routines.

As is generally known, the workflow application 40 may track theoperation of the batch executive 22 with respect to each order beingimplemented by the batch executive 22, and may allow the batch operatorto implement various operations or actions within or with respect to thebatch executive 22 or the process control network 20. For example, theworkflow application 40 may subscribe to certain types of data from thebatch executive 22, such as parameter data, batch state data, batchstate change data, batch alarms and/or alerts, etc., and may notify theoperator of various conditions in the plant 10 based on this data. Theworkflow application 40 may, for example, notify the operator of thestarting and stopping of various different batch procedures or of batchprocedural model state changes, may notify the operator of variousstoppages or other operational conditions of the batch executive engine22 (which may be caused by unforeseen problems such as missingequipment, missing raw materials), may notify the operator of timeperiods being out of place, batch parameters that may be out of rangebased on what the batch executive 22 is expecting, etc. The workflowapplication 40, as is known, may allow the operator to take variousactions to restart a batch run, to select different equipment for abatch run, to operate on different raw materials, to instruct the batchexecutive to start up, shut down, or skip procedures, or to executeother procedures in the batch procedural model. As an example, the batchexecutive 22 may try to go through a cleaning procedure wherein theequipment to be cleaned is off-line and thus unavailable to be cleaned.In this case, the operator may skip the cleaning procedure, which maynot be in strict compliance with the quality standards beingimplemented, but which may be necessary to complete the batch in atimely manner or within an allotted time frame. In any event, theworkflow application 40 may enable the operator to annotate variousactions taken by the operator. Moreover, the workflow application 40 maystore the annotations or notes provided by the operator via the workflowapplication 40 (e.g., notes or comments provided by the operator toexplain what happened and why the operator took certain actions outsideof the expected work flow of the batch process), and may store dataindicative of various actions taken by the operator via the workflowapplication 40 in the batch log file database 30 as part of a batch logfile 34 for the order being monitored or controlled. Each batch log file34 typically lists the various data that is obtained from the batchexecutive 22, along with actions taken by the operator in response tothat data, notes put into the log file by the operator, etc. Moreover,during operation of the batch executive 22, the batch executive 22 sendsdata packets to the workflow application 40 with current data pertainingto a batch run or order. The workflow application 40 may subscribe tovarious data from the batch executive 22 (or the process control network20) and may receive this data periodically, when changes in the dataoccurs, etc. Moreover, each set of data may have a unique packetidentifier that identifies various information about the batch run ororder associated with the data. In this manner, the workflow application40 can process the data packets to determine the order and thus theproper operator to whom to provide the data.

As is known, a batch log file or batch report 34 for a batch run isgenerated during the batch run and, after the batch run or order iscomplete, the batch log file 34 is complete. At that time, a qualityreview engineer or other personnel may access the batch log file 34 viasome viewing application executed on the computer or workstation 28, forexample, to analyze the batch report and to view the data and otherinformation within a batch report on a line-by-line basis. The qualityengineer may view this data, as it was stored during the operation ofthe batch process, in order to determine if any exceptions occurredwithin the batch run, if these exceptions need to be addressed, and whatif any actions need to be taken based on the existence of theseexceptions. As noted above, this review tends to take a lot of time, ismanually intensive, and requires a lot of knowledge on the part of thequality engineer. Still further, much of the time that the qualityengineer spends is simply looking at data or information from the batchreport that is not associated with any particular exception or deviationfrom expected actions within the batch run, and thus this review is timeintensive. Still further, as noted above, when a quality engineeridentifies an exception based on the data in the batch log file 34, thequality engineer may need to obtain other information about the batchprocess (e.g., process variable values, batch procedural model states,recipe information, etc.) stored in one of the other databases, such asin a batch historian 30, a process control historian 31, etc. Thisactivity may require the quality engineer to use other data accessapplications to access that data and thus requires the engineer to havethe know-how to access and view that data efficiently and correctlyusing these other data access applications.

FIG. 2 illustrates a plant environment 110 that is similar to the plantenvironment 10 of FIG. 1 with like structure, applications, and datahaving common reference numbers. However, the plant environment 110 ofFIG. 2 includes a quality review management system 112 that executes toassist quality engineers (or other personnel) in identifying andreviewing exceptions associated with an order or batch run (or withmultiple different orders or batch runs), and in some cases, whichassists operators in performing work flow operations within a batch runin a manner that reduces the number of exceptions or exception recordsgenerated during the order.

In particular, the plant environment 110 of FIG. 2 includes a processcontrol network 20 and a batch executive engine or batch executive 22,which operate in a manner similar to that described above with respectto FIG. 1. Thus, data from the batch executive engine 22 and/or theprocess control network 20 is provided to various devices via acommunications network backbone 25 to which various process control andvarious different quality review management system 112 computers ordevices are connected. In this example, the batch or other process datais provided to a workflow operator interface 26 which executes aworkflow application 40 and which provides data to a batch log filedatabase 32 which stores batch log files 34. However, the quality reviewmanagement system 112 within the plant environment 110 of FIG. 2includes various applications and databases that are located in, storedin, and executed on computer or processor devices within the plantenvironment 110. In particular, as illustrated in FIG. 2, the qualityreview management system 112 includes a configuration application 120stored in a memory of and executed on a processor of a processing device121, an exception engine 122 stored in a memory of and executed on aprocessor of a server 123, a rules database 124, an exception recorddatabase 126, and a quality review interface application 128 stored in amemory of and executed on a processing device, such as a workstation129. While the components 120, 122, 124, 126, and 128 are illustrated asbeing stored in and executed in separate computing devices differentthen the computing devices 26, 28, 30, 31, and 32, of FIG. 2, any subsetor are all of the components 120, 122, 124, 126, and 128 could be storedin and executed in the same processing devices, which may be the sameprocessing devices that store and execute other process controlapplications and databases, such as the devices 26, 28, 30, 31, and 32.

Generally speaking, the configuration application 120 may be operated orexecuted to enable a user, such as a configuration engineer, a qualitymanagement engineer, etc., to create and store a set of rules (generallyreferred to herein as exception rules) which may be used by theexception engine 122 to detect exceptions in the running of a process,such as in a batch run of a batch process associated with a particularorder. The configuration application 120 essentially provides aconfiguration environment that enables a user to create configurableexception rules to execute in the exception engine 122 to define ordetect exceptions. The configuration application 120 may store a set ofrule templates that may process various types of input data to detect anexception using any desired type of logic or logical expressions, suchas Boolean logic. In the configuration environment, a user may selectone of the rule templates, may define data inputs/outputs for a rule,and may define a possible expression to be analyzed for a set of data.When the data flows through the exception engine 122, the exceptionengine analyzes the data against the configured rules to determine if anexception exists. Upon detection of an exception the exception engine122 then stores an exception record in the database 126.

As an example, FIG. 3 illustrates a screen display 150 that theconfiguration application 120 may create and provide to a user (e.g., aconfiguration engineer, a quality review engineer, etc.) via theworkstation 28 of FIG. 2, for example, to enable the user to create oneor more exception rules 152 and to store the exception rules 152 in theexception rules data base 124. In particular, the configurationapplication 120 may enable the user to create different sets of rules tobe applied to data from different data sources. As illustrated in FIG.2, the exception rules 152 may include a different set of exceptionrules 152A, 152B, 152C, 152D, etc. for each of a number of differentdata sources. For example, the rules 152A may be created for andassociated with analyzing data from the workflow application 40, therules 152B may be created for and associated with analyzing data from anevent monitor application, the rules 152C may be created for andassociated with analyzing data from a third party application thatperforms other services in the plant environment 110, etc. Of course,any number of exception rules 152 can be created and stored for eachdata source and these rules may be configured in any number of differentmanners to analyze data from those data sources. For example, differentsets of exception rules may be created for different types of runs froma single data source (e.g., batches creating different products) anddifferent sets of exception rules may be created for different qualitystandards. Likewise, the exception rules associated with a particulardata source may be ordered to specify which of the set of exceptionrules should be executed or analyzed first, second, third, etc.

Referring again to FIG. 3, the configuration application 120 may createa screen that includes a number of different sections including a ruletemplate section 156, a data source section 158, a rules list section160, and a rule configuration section 162. The rules template section156 may include a set of icons indicating exception rule templates orpreviously configured exception rules stored as templates, which a usermay use as a starting point for creating a new rule. These templates maybe stored in the rules database 124 or in the same device as theconfiguration application 120 or in any other database or computermemory. The data source section 158 may include icons indicating variousdifferent data sources for which a user may create exception rules. Theicons 158A may be accessible to view specifics about the data sources,such as data available from the data sources, data or communicationformats used by the data sources to communicate data, information aboutthe data sources (e.g., manufacturer, version, etc.), and/or any otherinformation. The rules list section 160 may store a list of rules for aparticular selected data source and specify the execution order of therules when analyzing data from the data source.

During operation, a user may select a data source 158A from the datasource section 158 to specify the data source for which a rule is to becreated. The application 120 may access the rules database 124 and findthe previously stored rules (if any) for that data source and list theserules in the rule list section 160 in execution order, for example. Nextthe user may create a new rule for the data source by selecting atemplate data source icon 156A from the template section 156 anddragging and dropping that template icon 156A onto the ruleconfiguration section 162, which will cause the application 120 to loadconfiguration data for the selected template rule into various portionsor fields of the configuration section 162. If desired, the ruleconfiguration section 162 may have the fields thereof blank to enable auser to create a new rule without the use of a template. Still further,the user may select one of the rules in the rules list section 160 toedit a previously created rule. Of course, the application 120 may useother manners of selecting or establishing rules to be created (e.g.,using drop down menus, pop-up screens, etc.)

The configuration application 120 then enables a user, such as aconfiguration engineer, to specify, set up, or create the specifics ofthe rule by providing or editing various rule configuration informationin various fields of the rule configuration section 162. Basically, theapplication 120 enables the user to specify any rule configurationinformation needed to process data from the data source for the purposeof detecting and handling an exception within the operation of theprocess monitored by the data source. Generally, each rule stores logic,such as Boolean logic, to use to analyze the data from the data sourceto detect an exception, information on how to store an exception recordand, if desired, information on how to enable a quality engineer toprocess or resolve (e.g., close) an exception record created byapplication of the rule. Such exception rules may include, for example,detecting whether one or more parameters from the data source (e.g., theworkflow application 40, the batch executive 22, the process controlsystem 20, etc.) are out of range or are above or below certainpre-established thresholds; whether a note has been entered by anoperator (e.g., via the workflow application 40); whether differentmaterial is being used in a batch run for an order; whether differentequipment is being used for one or more batch procedures of an order;whether the processing times of one or more batch procedures has takenlonger or shorter than expected; the skipping or addition of certainsteps or procedures within a batch run for an order, such as a cleaningprocedure or a rinsing procedure; whether an operator or other user ofthe process system has taken an unexpected action in the process or hasentered a note in the data source application, etc. Of course, theexception rules may specify and desired logic to be applied toparticular data from a data source to determine if an exception exists.

Thus, as illustrated in the example screen 150 of FIG. 3, the ruleconfiguration section 162 includes a name field 162A which may be usedto specify a name of the exception rule, a severity field 162B which maybe used to specify a level of severity or importance of the exceptiondetected by the rule, and a logic field 162C which may be filled out orused to specify logic to be applied by the exception engine 122 (FIG. 2)to detect if an exception exists. Of course, the logic field 162C mayaccept or enable the user to enter or specify logic in any desiredmanner, such as a set of Boolean logic parameters or strings, coding ina particular language (C+, HTML, etc.), any desired custom expressionsyntax, etc., that applies some logic, If-Then logic statements, etc.Still further, a source parameter field may be used to specify any andall data that is needed from the data source for application of thelogic rule or logic as provided in the field 162C. This data sourcedata, which is referred to herein as data source metadata or justmetadata, specifies all of the data associated with the information,format, and communication parameters of data to be received from thedata source for the rule. The configuration application 120 may enablethe user to select one of the icons 158A to obtain configurationinformation for the particular data source for which a rule is beingcreated to determine what data source metadata (information and/orvariables) is available from the data source, the names of thesevariables, the data formats of these variables (e.g., 32 bit, 64 bit,variable types, such as integer or Boolean, or string variables), etc.Still further, the field 162D may enable the user to specify aconversion to be performed on a metadata from a data source prior to theinput data from the data source being used in the logic specified in thefield 162C. Such conversions may be mathematical operators (changingfrom Celsius to Fahrenheit, scaling, limits, etc.), the conversions maybe variable name changes (to match the various variable names used inthe logic to the data source variable name), or these conversions may beany other types of conversions. Moreover, the metadata from a datasource may include any desired information, such as process parametervalues, an order name, materials for the order, process flows for theorder, process equipment to be used in the order, work flows to beapplied to the order, the batch procedural model used in the order, etc.

Still further, the configuration engineer may use the configurationapplication 120 to specify the order or sequence in which each of therules of a particular set of rules should be applied to any particularset of data from a data source. In particular, the exception engine 122may apply multiple rules to each set of data from a data source and maybe set up to apply each of the multiple rules in a specific orpredetermined order so as to detect certain types of exceptions(typically more important or severe exceptions) prior to other types ofexceptions (e.g., less severe exceptions). For example, in manyinstances, the application of different exception rules to a particularset of data from a data source may result in the detection of multipledifferent exceptions. However, it may be important or desirable todetermine only the most significant exception for any particular dataset from a data source to prevent the creation of multiple exceptionrecords associated with the same event or time in a batch run or order.The order of the rules (i.e., the order in which the exception engine122 applies the exception rules to a particular set of data) is thusused to specify which exceptions are detected first so that, duringoperation, the exception engine 122 determines the exceptions based onthe various rules by running the rules in a particular order, and thensaving or creating an exception record for only the first detectedexception. As indicated above, the rules section 160 may store the listof rules for the source in the order that these rules will be executed.Each rule may, as a parameter thereof, store or include a sequencenumber or order number indicating this execution order. In any event,the user may change the order of the rules for a data source by, forexample, rearranging the order of the rules in the list of rules in thesection 160. The user may, for example, select a rule in the rule list160, drag that rule up or down in the list 160 and drop the rule in anew location in the list 160 to change the execution order of the rules.Of course, the application 120 may enable the user to change the orderof rules in other manners, such as changing an order field 162E in thescreen section 162.

Still further, if desired, the screen section 162 may include aresolution field 162F which may enable the configuration engineer tospecify one or possibly more handling or resolution procedures thatshould or must be applied to close an exception record created by therule. Generally, each type of exception may support a single resolutionprocedure. However, in some cases, exceptions may support or includemultiple resolution procedures. Such resolution procedures may includesigning off on the exception, annotating the exception record withvarious information, sending the exception record to other personnel toreview and/or sign off on, etc. In some cases, each resolution maysimply be a definition of a set of signatures needed to close theexception, or the resolution may simply enforce one or more signaturesneeded to close the exception. In these cases, the resolution mayinclude a description of or a set of instructions that indicate otheractivities (procedures) to be completed prior to the signature(s), butin these cases, the resolution may not monitor or enforce the otheractivities. The handling procedures as specified in the rule may bepreset or may be set to default settings based on, for example, theseverity of the exception as specified in the field 162B.

Still further, the screen section 162 may include an information field162G that accepts and stores information to be provided to the qualityreview engineer along with or as part of the exception record created byapplication of the rule. This information may be general informationabout this type of exception, normal handling procedures, directions orsuggestions as to other actions to take or consider, or any otherinformation that may be useful to the quality review engineer whenviewing or handling the exception record created by application of therule. In many cases, the field 162G may also be used to specify datasource metadata to be stored as part of the exception record, as well asthe format of displaying this metadata. Generally, when processing anexception record, it is helpful for the quality review engineer to knowthe context of the process at the time of the exception, and the datasource metadata may be provided as information to help the qualityreview engineer to understand this context. As such, the configurationfield 162G may indicate what data source metadata is to be provided tothe quality review engineer as part of the exception record.

Of course, the configuration application 120 may store any or all of therule configuration information as part of the exception rule in the ruledatabase 124 in any desired manner. As will be understood, thisconfiguration information may include the identity of data that isneeded from a data source and this data can be used, as will be laterdescribed, to obtain the correct data or information from a data sourceduring operation of the data source.

Of course, the configuration application 120 may be used to create anynumber of exception rules, and the exception rules may be stored in therules database 124 on a data source by data source manner, so thatdifferent rules or sets of rules may be made and stored for differentdata sources (or for different orders associated with a single datasource). In any event, the configuration application 120 may be used tocreate rules and may do so by enabling a user to create a new rule(e.g., from a template rule), may enable the user to specify a name forthe rule or exception to be detected by the rule, logic to be applied todata from a particular data source to be implemented to detect thepresence of an exception or a deviation from a norm based on the data,an identification of a type of rule or exception which the rule detects,a set of information to be provided to a reviewer or other user upon therule detecting an exception (such as an explanation of the exception,data or instructions useful for analyzing or signing off on theexception), an identification of a severity (e.g., importance) of theexception detected by the rule, metadata (e.g., data from the datasource) pertaining to the state of the process (e.g., batch run) at thetime of the exception that should be stored as part of the exceptionrecord, processes or procedures that may be used or must be used to dealwith or resolve the exception (e.g., sign-off procedures), and otherdata or information to be stored as part of an exception record or to beused in processing of an exception record.

Importantly, this configuration system or configuration application 120provides a significant advantage over known products, which require theexception software provider to hard code the exceptions defined for thesystem into the product, and thus require a software or system update tocreate new exceptions. These updates take time for the user to get andinstall, and do not enable users to customize their own systems.

After a set of exception rules is created for one or more data sources,and these rules are stored in the rules database 124, for example, thequality review management system 112 may thereafter implement theexception engine 122 in real time during operation of a data source todetect exceptions that may occur as a result of the operation of theunderlying process being monitored, controlled, or effected by the datasource application. When set up to run or execute on data from aparticular data source, the exception engine 122 periodically orintermittently receives sets of data (e.g., metadata) from the datasource indicating various operational parameters of the process and/orapplication that monitors or controls the process. For each set of data,the exception engine 122 obtains and applies the logic of the exceptionrules created for the data source to thereby detect exceptions in theprocess being implemented, managed, or monitored by the data source.When interfacing with or communicating with the data source, theexception engine 122 may receive sets of data from the data sourceperiodically, when some particular action or actions occur in theprocess or data source, and/or at other configured times. The exceptionengine 122 may subscribe to such data based on the data sourceconfiguration data within each of the exception rules for the datasource, may poll the data source for such data at various times or mayimplement a combination of these communication techniques. In thismanner, as the data source, such as the workflow application 40,operates to receive new data and to interface with an operator (e.g., toassist the operator in analyzing batch data from the batch executive 22for example), the workflow application 40 also sends data (periodicallyor otherwise) to the exception engine 122, which then analyzes the datausing the exception rules for the workflow data source application 40 todetermine if one or more exceptions have occurred in the underlyingprocess.

During this process, the exception engine 122, which is a logic engine,parses the data sent from the data source and applies the logic withinthe appropriate set of rules, such as the rules 156A in the database124, to thereby analyze the data according to the rules to detect one ormore exceptions. The exception engine 122 may apply the rules to thedata one by one in the order specified in the set of rules as stored inthe rules database 124, and may detect any exceptions as determined bythe rules or may stop processing the data when an exception is detectedby any of the rules on a particular set of data. Upon detecting anexception, the exception engine 122 creates an exception record for thatset of data and stores the exception record in an exception record file170 (FIG. 2) within the database 126. Of course, as each new set of datais provided by the workflow application 40 (or other data source) to theexception engine 122, the exception engine 122 processes that data forexceptions and determines if any exceptions exist, and then creates andstores exception records in exception record files 170 as appropriate.The exception engine 122 may store various different kinds of dataassociated with an exception record including, for example, a name ofthe exception identified or detected, a severity of the exception,review or resolution procedures to be applied, notes entered by theoperator as part of the data sent from the data source, generalinformation about the exception, etc. Still further, the exceptionengine 122 may provide, as part of an exception record, metadata that insome manner defines or is related to the operation of the batch or otherprocess equipment at the time of the exception. This metadata may beprovided to the exception engine 122 as part of the data from the datasource, or may be obtained by the exception engine 122 from the datasource (e.g., the workflow application 40), or from a database or othersource of that data separately from the data source. The metadata storedin the exception record may be any data that defines some operationalparameter, value, state, or other information associated with theprocess being implemented at the time for which the exception isdetected. This metadata may be, for example, batch state information,process parameter values as measured or determined from the process,process equipment information, alarm or alert information from theprocess equipment, or any other information. Moreover, this metadata maybe obtained from other sources, such as batch log files 34, processcontrol databases or historians 31, process equipment, batch historians30, etc. or may be provided directly from the data source itself, aspart of the initial data processed by the exception engine 122 or inresponse to a query by the exception engine 122. Generally speaking, thestored metadata provides a snapshot of the process (e.g., process stateinformation, process equipment information, process variable values,batch procedural model states, etc.) at the time that the exception wasdetected. This metadata may be displayed as part of the exception recordto enable a quality engineer to understand the context of the exception(e.g., what was happening in the process at the time of the exception)to thereby better understand the exception and the importance of theexception.

As will be understood, the exception engine 122 operates in real time,that is, in an ongoing manner in tandem to the data source, to analyzethe data from the data source for exceptions and to store exceptionrecords for detected exceptions in an exception database 170. Theexception engine 122 may operate to receive new sets of data packetsfrom the data source, such as a workflow engine 40, for any period oftime. For example, the exception engine 122 may analyze data from theworkflow application 40 as a particular batch process is run and mayhalt upon completion of the batch process or order. Of course, theexception engine 122 may operate to analyze and detect exceptions formultiple different batch runs simultaneously, for example, from the samedata source (e.g., the workflow application 40), and/or may analyze datafrom different data sources simultaneously. In all of these cases, theexception engine 122 may create and store exception records for eachdifferent batch run of a single data source and/or for each differentdata source simultaneously. Thus, the exception engine 122 mayunderstand that different batch runs are occurring at the same time orthat data from different sources are being processed over the same timeperiod, and may track these runs and processes separately to createdifferent exception databases 170 for each batch run, order, and/or datasource.

FIG. 4 illustrates the operation of the exception engine 122 on multipledifferent data sources 180, 182, 184, and 186. The data sources 180-186may be the same types of data sources (e.g., different instances ofworkflow applications 40 running different batches or making differentproducts), and/or may be different types of data sources, such as eventmonitoring applications or systems, third party proprietary systems orapplications, etc. In this case, the exception engine 122 and/or thedata sources 180-186 are configured to periodically receive and senddata packets 188 with data source metadata to the exception engine 122.These data packets 188 may be formatted to include data from the datasource as specified by the metadata configuration information within therules for the data source and these data packets 188 may include anidentifier of the data source, the order being implemented by the datasource, the data source metadata, etc.

The exception engine 122 receives and processes each of the data packets188 from different data sources 180, 182,184, and 186, in turn as thesepackets are received. For each packet 188, the exception engine 122 maydetermine the identity of the data source and order (as specified bydata within the data packet 188), may obtain the appropriate set ofrules from the rules database 124 for that data source, and may applythe obtained rules in a predefined order to the data within the datapacket 188 to determine if an exception exists. If the exception engine122 processes through all of the rules for a data source withoutdetecting an exception, the exception engine 122 then waits for orbegins to process the next data packet 188 (from the same or a differentdata source). If, on the other hand, the exception engine 122 detects anexception based on the application of the rule logic to the data sourcemetadata, the exception engine 122 creates an exception record 180 forthe order and stores that exception record in an exception recorddatabase 126 as an exception record file or database 170 for an order.That is, all exception records for a particular order may be stored as aset of exception records for that order. In any event, as indicted bythe diagram of FIG. 4, the exception engine 122 may operatesimultaneously on data from various different data sources and/or forvarious different orders (from the same or different data sources) toproduce exception databases for each order.

One additional benefit of the exception engine 122 is that it operatesin real time, i.e., during operation of the underlying process, and socan detect the occurrence of an exception in real time, e.g., as theexception occurs. As a result, one feature of the exception engine 122is that, upon detecting the occurrence of an exception, the exceptionengine 122 can immediately or in real time notify the operator or someother personnel at or associated with the data source of the existenceof the exception, which may enable the operator or other person to takeactions within the process to mitigate or avoid the exception. In somecases, exception rules may be configured to detect the possibleoccurrence of a future exception based on actions or states of thecurrent process. In this case, the exception engine 122 may detect thepossible or likely occurrence of an exception and may notify theoperator or other user, in real time, that an exception is likely tooccur. This notification provides the operator or other user an abilityto reverse some action or change some parameter that is at the rootcause of the future exception, before the exception occurs. This livefeedback can therefore be used to avoid or immediately mitigateexceptions by enabling the operator or other process monitoring orcontrol personnel to take actions to avoid or reverse the conditionsleading to the exception.

FIG. 5 illustrates a screen display 200 that may be provided by, forexample, the workflow application 40 of FIG. 2 to an operator as part ofnormal operation of the workflow application 40. In this case, thedisplay 200 may provide process information in the form of a process orwork flow diagram 202 to the operator and may enable the operator totake some action or actions in the process via input fields 204. In thiscase, the operator may change a setpoint of a particular processparameter using the input field 204 in the screen 200. However, as theoperator enters a new setpoint, or immediately after doing so, theworkflow application 40 sends a data packet to the exception engine 122with data indicating this change. In this example, the exception engine122 may be programmed to implement a rule to determine if the value ofthe process parameter is within a particular range (as this processparameter may be a critical process parameter for quality purposes). Theexception engine 122, upon running the rule, may detect that thecritical parameter is being set out of the desired range and will thusresult in an exception if the setpoint is changed. The exception engine122 may then immediately send a notification via a live feedback messageto the application 40, which may result in a notice or alarm beingprovided to the operator. For example, as illustrated in FIG. 5, apop-up box 206 may be created in the screen 200 based on the livefeedback message, telling the operator that the contemplated action orthe just taken action will (or did) result in the creation of anexception record. This message in the pop-up box 206 may instruct theoperator to take an action to avoid or to mitigate the exception (if italready occurred). Thus, as will be understood, rules as created andstored in the rules database 124 for a data source may pertain todetecting actual exceptions and/or to detecting the likely occurrence ofa condition leading to an exception in the future. Moreover, the livefeedback feature of the exception engine 122 may be used to enable auser to avoid the occurrence of an exception in the future or tomitigate or reverse the conditions leading to a currently detectedexception. Because this notice is in real time to the operation of theprocess, it is much more likely that the effect of the exception can bereversed or mitigated using this live quality feedback technique.

While FIG. 2 illustrates the operation of a quality review managementsystem 112 in a process plant environment 110 in which various portionsof the system 112 are executed in dedicated servers and databases, thequality review management system 112 may be implemented in a plug-inenvironment, making the system much more portable, able to be moreeasily used on mobile or distributed devices, easy to maintain andimplement in a distributed environment, and easily configured for usewith third party systems or applications. In particular, FIG. 6illustrates the quality review management (QRM) system 300 implementedusing plug-ins. The quality review management system 300 of FIG. 6includes a quality review services device 302 (which may be stored inand executed on a server or other computing device) that iscommunicatively coupled to various data sources 304A, 304B, 304C, etc.,a rules database 124 and a configuration application 122. Still further,the quality review management services device 302 is coupled to variousplug-ins 310, 312, 314, 316, etc., which may be stored in and run in anydesired computing device, such as in workstations within or outside ofthe plant environment, in mobile devices, such as in laptops, phones,etc., or in any other device. The plug-ins 312-314 may be created(instantiated and spun off) as needed for any particular order or datasource. In this case, each plug-in 310-316 may be created for aparticular data source and/or for a particular order within a datasource to analyze the data from that data source for exceptiondetection. Plug-ins may be destroyed when the order or application iscomplete or finished.

Generally speaking, the QRM services device 302 may, in response to aconfiguration application 120, create a particular plug-in for aparticular data source or a particular order from a particular datasource. Each plug-in 310-316 may include configuration informationprovided as part of the configuration of the plug-in 310-316 to informthe plug-in 310-316 of the data and data format of information that willbe sent to the plug-in 310-316 for evaluation, the location at which tostore an exception record file or database for the data source or order,and any other desired configuration data needed for operation of theplug-in 310-316. Moreover, if desired, the configuration data for theplug-in 310-316 may include one more rules to apply or analyze based onreceived data. Of course, each plug-in 310-316 can be associated with(configured for) the same data source or for different data sources andso the configuration information for each plug-in 310-316 can be similaror vastly different depending on the data source or use of the plug-in310-316. The configuration information of each plug-in 310-316 may alsospecify the data to be subscribed to or to be received from the QRMservices device 302 or from a third party application or source duringoperation, and the plug-ins 310-316 may register with the QRM servicesdevice 302 or other applications or sources to receive that data.Generally, the plug-ins 310-316 may operate simply to obtain specificdata from a data source and so need only to be configured to understandwhat data is coming from the data source, and the format of that data.The plug-ins 310-316 can then receive and process the data from the datasource and put the received data in a format for use by the exceptionrules as created for the data source. In this manner, the plug-ins310-316 may operate as data gathering and interpretation applicationsfor any types of data sources, even third party or proprietary datasources.

Moreover, each plug-in 310-316 may include a runtime processingconfiguration that defines or controls the operation of the plug-in310-316 during operation. This runtime section may include a logicparser that uses rules or logic within the exception rules for a datasource to analyze received data from a data source and to create andstore exception records in an exception record database or log 170. Inessence, the runtime section of a plug-ins 310-316 implements theexception engine 122 of FIG. 2 on an instance by instance basis. Thus,as noted above, the plug-in modules 310-316 may be created to interfacethe exception engine 122 with external or third-party systems (e.g.,control systems, OPC interfaces, maintenance systems, etc.); therebyenabling exceptions to be generated based wholly or in part based ondata from third party or external software systems. In one example,plug-ins are created to access particular data within or from a thirdparty or external system and to pass this data to the exception engine122 to analyze whether an exception should be created or not. However,the plug-ins 310-316 may be stored in and executed in a third-partyserver, in the QRM services device 302, or in another server, mobiledevice, or other processing device.

As an example, the configuration application 122 of FIG. 6 may be usedto create one or more plug-ins 310-316, including specifying the formatof data to be received from the data source to be analyzed by theplug-in 310-316, how often the plug-in 310-316 should receive data fromthe data source, the identity of an order and other information aboutthe data source, the type of application to which the plug-in 310-316will be used to process, etc.

Moreover, the plug-in modules 310-316 may be created with dataacquisition functionality and with runtime exception processingcapabilities if so desired. Once created, the plug-ins 310-316 may bestored in and executed in any convenient location or processing device,such as a device close to the data source or data sources. Moreover, theplug-ins 310-316 may register with the data services device 302 (or withany other server or device) to receive data from the appropriate datasource, such as one of the data sources 304. The QRM services device 302may then subscribe to or poll the data sources 304 for the appropriatedata, and upon receiving a data packet from a data source, may providethe data and one or more exception rules for the data source to theplug-in module 310-316 to be used to analyze that data. The plug-in310-316 may then use the rule or rules in the logic engine thereof toanalyze the data for exceptions, and upon detecting an exception, maystore an exception record in an exception record database 170 for thedata source. Thus, as will be understood, the QRM services device 302acts as a data broker for the plug-ins 310-316, which can operateindependently of one another on any desired device using any data ordata obtained from different sources.

As will be understood, the quality review management system 128 mayimplement the use of plug-ins or plug-in modules on a source-by-sourcebasis to execute the functionality of exception engine, as describedherein, to enable the quality review management system to be easilyconfigurable for different data sources, for different quality reviewstandards, and/or to be easily run in a distributed environment in whichvarious different parts of the system are executed in differentcomputers spread throughout a plant. In this case, a different plug-incan be created for each various type of data source, and each plug-incan have its own set of rules associated therewith to be used to performexception detection from a particular data source.

Moreover, the plug-in modules 310-316 may or may not perform exceptionprocessing and detection in a batch or order processing environment. Insome cases, for example, one or more of the plug-ins 310-316 may becreated to perform or enhance process or event monitoring within aplant, or to perform quality review within a plant, such as within acontinuous process manufacturing plant. Thus, the plug-ins 310-316 maybe simple third-party system data gatherers, or may gather data andadditionally perform some exception processing, or may provide anexception or pre-processed exception data to a stand-alone exceptionengine. The use of plug-ins to implement quality review is advantageousbecause known quality review products are unable to interface with orcreate exceptions based on data provided directly from external softwareprograms, like control systems, safety systems, maintenance systems,etc. Moreover, the use of a plug-in module environment makes the qualityreview management system 112 described herein much more robust in acomplicated process environment having multiple different softwaresystems operating during runtime.

FIG. 7 illustrates an example of a data or event monitoring system usingthe quality review exception processing techniques described herein. Inparticular, FIG. 7 depicts a high level diagram of a process plant 400that may run continuous processes or process equipment. As illustratedin FIG. 7, the process plant 400 includes process control equipment 402that may be associated with, for example, running or implementing acontinuous process (such as a crude oil refinery process), or a batchprocess, or both. The process plant 400 may include one or more batchexecutives 404 connected to the process control equipment 402, and oneor more operator interfaces 406 that monitor one or more sections orparts of the process control equipment 402. Still further, the batchexecutives 404 and operator interfaces 406 may be connected to a masterplant control device 410 which may store configuration and controlinformation for the plant 400. Still further, the plant 400 may includeone or more application servers 411 which may run other applications,including for example database applications, monitoring applications,plant analysis applications, etc.

In many cases, the plant assets within the plant 400 run proprietary orthird party control, monitoring, and asset management systems thatcollect a great deal of data from the plant during operation. Moreover,the operator monitoring applications and interfaces 406, the batchexecutive 404 or other control applications may also be priority innature. It is known in process control technology to use OPC interfacesto obtain data from various third party or proprietary applications.Thus, each of the operator interfaces 406 may include an OPC alarms andevents (OPCae) 412 or an OPC data access (OPCda) interface 412, forexample, to enable detection and use of alarm and event data (asgenerated in the plant 400 such as in the process equipment 402) orother process data to be used by external systems. Additionally, in somecases, one or more monitoring applications 414 may be stored in one ormore of the plant devices, such as in the application server 411 or aseparate event monitor server 416. The event monitoring applications 414may be known applications used to interface with one more of the batchexecutives 404 to obtain process event information (but not necessarilyvia an OPC interface) and/or may be configured to interface with one ormore of the OPCae or OPCda interfaces 412 to obtain alarm and event dataor other data from the process control network 402. The event monitorapplications 414 are traditionally used to obtain process data, such asevent and alarm information, from the plant assets and to store thatdata in a database for later review or use in various systems, such asprocess control analytic systems, maintenance systems, etc.

However, the exception processing structure described herein may be usedto process alarm and event and other information as obtained from theevent monitoring applications 414 to determine if certain plantconditions occur within or during operation of the plant equipment 402.Such conditions may include, as examples only, when certain events oralarms reach a critical level, when a certain set or combination ofalarms or events occur together, when various process conditions exist,or any other set of conditions that indicate an issue that may need tobe noted to a user of some sort, such as a quality review engineer, asafety engineer, etc. To perform this function, an event monitor plug-in450 of FIG. 7 may be used to access data from one or more of the eventmonitoring applications 414 within the plant 400, one or more of theOPCae and/or OPCda interfaces 412 within the plant 400, etc. The eventmonitoring plug-in 450 may receive data from the event monitoringapplications 414, OPCae and OPCda interfaces 412, or other data sourcesin the plant 400, and may perform exception rule processing to detectthe existence of certain, typically more complex conditions in the plant400. That is, there may be conditions in the plant 400 that a qualityreview engineer, a safety engineer, a maintenance engineer, a processcontrol engineer, or other person may want to know about but which arenot otherwise detected by the process control or monitoring systems asthese systems are set up and running the plant 400. Generally, theseconditions may not be simply determined by single alarm or eventnotification generated in the plant 400, but may instead need to bedetermined by the existence of a more complex set of conditions in theplant 400, such as an alarm over a certain critical level, a certainnumber of alarms of some type occurring at the same or at approximatelythe same time, an alarm of a certain type or severity in conjunctionwith one or more other events in the plant 400, etc. As will beunderstood, the plug-in module 450 may include or provide access to anexception engine (as otherwise described herein) that operates withrules implementing logic to determine these “exceptions” in theoperation of the plant 400. Thus, the event monitor 450 of FIG. 7 maycollect data from third party applications (event monitoringapplications 414) or systems (event monitor servers 416) or interfaces(OPCae interfaces 412) and may process this data using a set ofpreconfigured rules to perform enhanced event detection or processmonitoring or exception processing for quality review purposes. In thiscase, the event monitoring application 450 (which may be located in adifferent environment from the plant environment, as noted by the dottedline of FIG. 7), may provide the results of the rule analyses to amonitoring interface 452 and/or to a database 454, such as an SQL(Sequel) database for later review. In essence, the event monitoringplug-in 450 operates to detect “exceptions” in the operation of theplant equipment 402 based on event monitoring data collected by theplant equipment 402 and provided to third party applications orinterfaces in the plant 400. This type of monitoring is still referredto herein as exception processing, as this monitoring detects exceptionsin the operation of the plant 400, even if it is not performed as partof a quality review process.

In any event, the event monitor 450 may be tied to any of one or morethird party or external systems and may be used to generate and sendmessages to a rules engine (not shown) which can then use these messagesto perform exception processing or exception creation in the form ofmonitoring messages, notifications, alarms, etc. In one case, theinternal event monitor 450 may be tied to or coupled to an OPCaeinterface 412, and may recognize when one or more alerts or alarms arepassed from the OPCae interface 412. At this time, the event monitorapplication 414 or OPC interface 412 creates and drops a message to theexternal event monitoring system 450 with the alert or alarm informationand potentially any other desired OPC collected data. The system 450 maythen analyze the messages to generate exceptions based on the data inthe messages. This operation is advantageous because known qualityreview systems do not analyze data from third party systems, and are notconnected to the OPC alert and alarm interfaces that exist. As such,these systems are not able to generate exceptions based on processalarms and alerts, for example.

Generally speaking, the event monitoring system 450 of FIG. 7 can beconfigured in a number of different manners to collect and process alarmand event data from the process control system 402, to produce anenhanced monitoring system using exception processing. In particular, auser can configure the event monitoring system or module 450, which maybe a plug-in as described above; to subscribe to and collect data (e.g.,event and alarm data, messages, etc.) as collected by the OPCae andOPCda interfaces 412 of FIG. 7, for example. The event monitoring server416 which collects this data can then send this data in data packets tothe event monitoring application 450 along with other information, suchas timing information, process control metadata (obtained from the OPCinterfaces 412, the batch executive 404, the process computer 410,etc.). The event monitoring system 450 can then apply a set of rules tothe data, as described above, to determine if any event monitoringexceptions exist based on the collected events and alarm data and therule logic. If an exception is determined, the event monitoring system450 may create a message (based on the rule) and send that message tothe monitoring interface 452 for display to a user and or to a databaseor message queue 454 in, for example, a Sequel server. The rule thatgenerated the exception can, of course, specify the content of themessage, the format of the message, the information to be placed intothe message, the interface(s) to which the message is to be sent, etc.Additionally, or instead, the event monitoring system 450 can create andsend an exception record to a monitoring database for storage and laterretrieval. This exception record (which is a monitoring conditionrecord) may include any desired information based on the ruleconfiguration, and can include, for example, an explanation of theevent, the severity of the event, instructions for dealing with theevent, process metadata at the time of the event, etc. As will beunderstood, in this case, the rule logic for the event is processed inthe event monitoring system 450 (or in an exception engine coupledthereto) and can be processed in or using a plug-in environment such asthat of FIG. 6 or in a traditional server environment such as that ofFIG. 2.

In another case, the event monitoring system 450, based on itsconfiguration, can configure the OPC interfaces 412, for example, todetect certain conditions or combinations of conditions and to then sendthe event monitoring system 450 a message when these conditions are met.In this case, the event monitoring system 450 essentially programs theOPCae or OPCda interfaces 412 to perform the logic of the rule and toonly send messages or data to the event monitoring system 450 when thatlogic is satisfied. Upon receiving a message from the OPCae interface412 with a message indicating that a particular set of conditions orlogic is met, the event monitoring system 450 can simply create and senda communication to the event monitoring interface 452 and the database454 to notify a user of the condition and to store an exception recordin the database 454. In this case, the logic of the rules for the eventmonitoring system are executed wholly or partially in the OPC interfaces412 or external event monitoring applications 414, 416, which may beconfigured using known techniques to implement this logic and onlysending messages when certain conditions exist in the process plant 400.

Thus, in the example system of FIG. 7, the exception based processing ofthe quality review management system described herein may be used toanalyze, review, or detect exceptions in data from third-party systemsthat do not use the same data format as, for example, the workflowapplication 40. While in the case of FIG. 7, the quality reviewmanagement system is illustrated as being used as an event monitoringsystem to interface with batch or continuous process control system viaone or more OPC interfaces 412 to determine monitoring based exceptionsbased on the existence of various events, alarms, parameter settings,etc., the quality review management system described herein could beconnected to third party process equipment, servers, applications, etc.via any other desired interfaces.

Referring back to FIG. 2, the quality review interface application 128may be executed to enable a user, such as a quality review engineer, toaccess one or more exception record databases 170 for a one or morebatch runs, orders, process operations, etc. from a particular datasource. The quality review interface application 128 may, for example,enable a user to step through each of the exception records in anexception database 170 one by one to view the detected exceptions and toresolve these exceptions, such taking any necessary actions to close theexception records. The quality review application 128 may present, viaan interface screen of an interface device, data or information for eachexception record, such as the name of the exception, the type ofexception, the severity of the exception, the batch metadata or snapshotinformation stored for the exception record, notes created and stored byan operator that are associated with or that caused the exception recordto be created, any other information provided by the data source, etc.This information enables the quality reviewer to quickly understand theexception and the context of the process (e.g., the batch run) at thetime of the occurrence of the exception to be better able to understandthe exception and the importance of the exception. The quality reviewinterface application 128 may also present various other types ofinformation to the user in a structured manner, such as generalinformation about this type of exception, what steps need to beperformed to handle or sign off on this type or severity of exception,etc. Still further, the quality review interface application 128 mayenable the user to take one or more of the various steps needed to signoff on or close the exception, such as implementing one of the variousprocedures as defined by the original exception rule that detected theexception, in order to sign off on or handle the exception. The qualityreview application 128 may, for example, enable the user to click acheck box on the screen to acknowledge and sign off on the exception,may require or enforce a process that includes having one or more otherpeople view and sign off on the exception in order to close theexception, etc. Still further, the quality review interface application128 may be able to send the exception record to other people via emailor other network communications, in order to obtain a sign off on theexception, to ask questions or provide data or notes about theexception, to determine more information about the exception, or toimplement procedures necessary to handle or close the exception.

FIGS. 8A-8G depict various example screen displays that may be createdby the quality review interface application 128 to enable a reviewer tosee and manipulate exception records in the process of performingquality review of, for example, an order. As an example, FIG. 8A depictsa screen display 500 that may be used by a reviewer to select one of aset of various orders or exception record files to review. The screen500 includes a section or field 502 that lists various data sources(e.g., in a drop down menu format) for which exception record logs 170exist (as stored in the exception record log database 126 of FIG. 2 forexample). Moreover a section 504 may list a set of orders or exceptionrecord files 170 that exist for the selected data source in section 502.Thus, in the example screen 500 of FIG. 8A, the field 502 lists theworkflow data source and the section 504 lists a number of variousexception record files for orders or batch runs managed by the workflowapplication. Still further, a section 506 may list the exception recordswithin a particular file (e.g., order) as selected in the section 504.The user may scroll down through the list 506 to select different onesof the exception records 506A-506N. Still further a section 508 of thescreen 500 may present information for the exception record 506A-N asselected in the section 506. In this example, the user has selectedexception record 506B and the application 128 obtains information forthe selected exception record 506B from the exception record logdatabase 126 and displays that information for use and manipulation bythe user. The section 508 may include various information for theselected exception record, such as the name, type, severity, informationfor and review or handling procedures for the exception.

Importantly, the displayed information for the exception record mayinclude process or data source metadata 510 as collected from the datasource at the time of the creation of the exception. As described above,the quality review management system 112 collects a set of metadata(which may be predefined when, for example, creating a plug-in or a ruleor which may be data known to be provided by a particular data source)when collecting the input data from a data source. Generally, themetadata to be collected is defined by a data transform that isconfigured when creating a rule. The data transform is applied to themetadata from the data source and the plug-in outputs this transformedmetadata in, for example, HTML, so that the metadata is viewable in thereviewing application. This data source metadata, which may be anyprocess or environment data, is generally collected at the same time asthe exception input data, and is stored as a process snapshot associatedwith the accessed exception data as part of the exception record createdfor the exception. As such, when the exception engine 122 detects anexception based on the collected exception data, the exception engine122 also stores the data source metadata as part of the exceptionrecord. The quality review interface application 128 then displays someor all of this metadata in, for example, the field 510 of the screen 500reporting the generated exception, thereby providing the reviewer with alive view into the process at the time that the exception arose withinthe process. This feature thus provides the reviewer with a quick viewof various process states/values, etc. at the time of the exception,which enables the reviewer to more quickly understand why the exceptionarose, the context of the exception, etc., thus enabling the reviewer tomore quickly process or know how to resolve the exception. Thisoperation makes quality review easier because, while known qualityreview products generally provide a list of generated exceptions to areviewer, the reviewer must still analyze each exception to determinewhether the exception can be dismissed or must be dealt with in someother manner and, in these known products, the reviewer must typicallygo back to the process system in which the data that lead to theexception was collected to get process snapshot data at the time of theexception. With the live view feature provided by the metadata field 510of the screen 500, the reviewer is automatically provided with a processsnapshot that will generally include the process data most useful to thereviewer in performing exception review, which means that the reviewerdoes not need to go back into other data collection systems to get theinformation the user needs to perform exception review and handling.This feature also means that the reviewer does not generally need to beas familiar with other process data retrieval systems from which theprocess or data source metadata is usually collected, as the reviewerwill not generally need to use those data collection systems to accessthe process data the reviewer needs to resolve exception records.

Still further, as illustrated in FIG. 8A, a section 512 may provide theuser with a set of options or information with respect to the manner ofhandling or resolving the exception, e.g., review steps or procedures,checklists of actions to perform to close the exception, sign off fieldsneed to be filled out or signed by various users to close the exception,etc.

FIG. 8B depicts an example screen display 520 illustrating some of theinformation for an exception record of the type Workflow Comment. Here,the workflow exception in the screen section 506 is the only exceptionlisted for the selected order. As illustrated in the section 508 of thescreen 520, the workflow comment has a status of NEW, a severity of LOW,does not have or is not associated with a corrective and preventativeaction (CAPA) identifier (which may be used to define a reference to athird party system that may also be used to view and/or process theexception) and also is not assigned to any groups. The section 508however displays an exception ID (as each exception will have a uniqueID), a source indication, and a creation date/time for the exception,all of which data is stored as part of the exception record. Stillfurther, the section 508 includes a general description of the exceptionwhich may also be information stored as part of the exception record.However, this data may be stored as part of the review application 128and may be based on the exception type.

Likewise, the bottom portion of the screen section 508 depicts themetadata collected for this particular exception. In this case, themetadata reflects what a user was seeing in the workflow applicationwhen the exception was created and may be used to assist the reviewer inunderstanding the context of the process when the exception occurred.

Still further, an example screen 530 of FIG. 8C provides a list ofresolution fields that may be provided to a reviewer within the screensection 508 of FIG. 8B to perform handling or closing of an exceptionrecord. Here, the resolutions may be configurable as desired (and thus asimilar screen may also be used in the configuration application 120 togenerate a rule for an exception). In any event, as indicated in FIG.8C, the resolution fields may include a resolution name or type 532(e.g. standard), a description 534, one or more stage names 536 (e.g.,Manufacturing or Manufacturing Supervisor), a severity 538 (e.g. Low),and signatures 539 needed by personnel in one or more stages to close orresolve the exception. In this case, the resolution of the exampleexception record displayed in FIG. 8C indicates that the exception mustbe signed by two operators (in the manufacturing stage) and onesupervisor (in the manufacturing supervisor stage) to close or resolvethe exception. These handling procedures may be implemented in thesection or field 512 of FIG. 8A in the form of signature boxes, checkboxes, etc. Moreover, the reviewer may be able to change theseprocedures on an exception by exception basis or may be able to groupexceptions and take steps based on the group.

FIG. 8D, as an example, illustrates an example screen display 540 thatincludes a screen section 508 having a resolution field 542 for aselected Parameter out of Range exception. Again, here, the screen 540includes some information about the selected exception record, includinga status (Active), a severity (Low), a CAPA identifier and a groupdesignation if any. The resolution section 542 includes fields 544 thatenable the reviewer to browse to attach a file to the exception record(which may be useful later when the exception records for the order arebeing reviewed by a customer, the FDA, etc.), and a comments field 546which enables reviewers to add comments or notes to the exception record(here an SA administrator has commented that she will take care ofclosing the exception record). Of course, additional comments can beadded using the field 546. Additionally the screen section 508 of thescreen 540 includes a sign and close field 548 which may be used by thevarious required signatories to close the exception record. Stillfurther, the screen section 508 may include a history field 549indicating actions taken to the exception record while processing therecord, including what action was taken, who took the action and thetime and date of the action. This information may be captured by thereview interface application 128 and stored as part of the exceptionrecord.

Likewise, the various screens presented by the quality review interfaceapplication 128 may include statistical information about an order or agroup of orders. For example, a section 550 of the screen 540 includesan indication 551 of the order being viewed, an indication 552 of thenumber of exception records associated with the order that are closed,and an indication 553 of the completion status of the order (in thiscase the order is not yet complete but is still being processed). Thesection 550 may also provide links 553 for reviewers to sign and verifythe order or exception records of the order, etc.

Likewise, a screen 560 of FIG. 8E illustrates additional statisticalinformation that the quality review application 128 may determine andprovide to a reviewer on an order by order or group by group basis. Thescreen 560 of FIG. 8E is similar to that of 540 of FIG. 8D except that asection 562 displays various statistical information about the 11exception records in the selected order. In this case, the boxes 564indicate the number of exception records for the order that are in eachstatus category (New, Active, and Closed). Moreover, bar graphs 566indicate the number of exception records for the order by each severitycategory (five are low, three are medium, two are high, and one is new).Still further, bar graphs 568 indicate the number of exceptions of theorder in each exception type (nine are parameter out of range type, andtwo are comment type). Of course, the quality review application 128 mayprovide other types of statistical information about exception recordsand may provide statistical information in other manners, such as forgroups of orders, subsets of records within an order or group, etc.

Still further, the quality review interface application 128 may enable areviewer to group various ones of the exception records together into agroup and take various actions (commenting on, changing parameters of,signing off on, etc.) of the records as a group. As an example, each ofthe screens 540 and 560 of FIGS. 8D and 8E include a listing 570, withinthe list of exception records, of three groups of records, namely FirstGroup, Second Group and Tester. The application 128 may enable areviewer to add exception records to a group by, for example, selectingan exception record in the exception record list 506 and dragging anddropping the selected exception record to a group in the list 570. Ofcourse, the application 128 may enable a reviewer to create new groups,delete groups, etc. as desired in any suitable manner.

Still further, the application 128 may enable a reviewer to take one ormore actions to exception records on a group basis, which saves time forthe reviewer. FIG. 8F depicts an example screen 580 in which a reviewerhas selected the group Tester for a group action. As a result of thisselection, the application displays a pop-up window 582 of potentialactions to be taken on the group of exception records in the groupTester. Such actions may include changing the severity of the exceptionsin the group (via a drop-down input box 584), changing the CAPAidentifier for the exception records in the group (via a drop-down inputbox 586), adding a comment to each of the exception records in the group(via an input box 588), attaching a document to each exception record inthe group (via a box 590), and signing and closing the exception recordsin the group via a link 592. Of course, the application 128 may enablethe reviewer to take any other action or actions on a selected group ofexception records and may do so in any other manner via an interfacedevice.

If desired, the quality review interface application 128 may enable areviewer to take group actions on exception records not actuallyassociated with a group. For example, as illustrated in an examplescreen display 592 of FIG. 8G, the reviewer may select a check box forvarious exception records in the list 506 (the first two exceptionrecords are so checked in the example of FIG. 8G). The application 128may then recognize this as an attempt to take actions on both of thechecked exception records and may provide a pop-up screen 594 includingthe various edit fields of FIG. 8F. However, in this case, the pop-upbox 594 may include grouping actions that can be taken on the selectedexception records, such as adding them to an existing group or creatinga new group, as shown at the top of the pop-up box 594 of FIG. 8G.

The quality review interface application 128 as described herein may usean advantageous paging algorithm or technique to enable a reviewer toscroll through various pages of records, such as exception records asprovided in the record lists 506 of FIGS. 8A, 8B, and 8D-8G, in a mannerthat reduces or eliminates presenting duplicate records in differentpages or in missing records in the display when going between pages ofrecords. Generally, web-based or browser based display systems that usea browser to display lists of organized records stored in a exteriorstructured database, such as an SQL database accessible via a networkconnection for example, search for the relevant records in the databaseand then present a number of the records that will fit onto a displaypage, e.g., 10 records at a time. Thus, these systems will typicallyfirst display the records in the first ten positions of the returnedlist. When the user wishes to see more records outside of the currentlydisplayed list, the browser contacts the database with the same searchand obtains the next set of records (e.g., the next 10 positions ofrecords) if the user is scrolling down in the list of records or theprevious set of records (e.g., the previous 10 positions of records) ifthe user is scrolling up in the list of records. Of course there can bea large number of exceptions or records and so the interface must scrollthrough numerous pages of records as the user scrolls down or up thelist of records. Thus, the browser of the display system will determineall of the relevant records associated with the query and present afirst page as the first X number of records in the list, (e.g., if X is10, records 1-10). When the user wants to look at records not in thefirst page, the system loads a second page as the second set of Xrecords in the list (e.g., records in positions 11-20 of the list). Thesystem then scrolls up or down in the list by X positions to present anearlier or the next page of records. When the list of records is staticand does not change very often, this paging algorithm works well, as thesystem simply loads consecutive sets of X number of records as each newpage.

However, when the records in the list or search change, such as whensome of the records disappear or fall off of the search because someparameter of the record is changed, or when new records are created inthe database, the original list of records found by the search changes,and these changes may occur during the time that the reviewer isreviewing one page of records but before calling the next page ofrecords. In this situation, as the reviewer processes the records andscrolls down the list of records as displayed on the user interface, therecords may change in the database, and thus the page data may becomeout of date. In particular, records may be added or may be deleted fromthe database (or records may have parameters that change that cause therecords to no longer be returned by the search according to the searchcriteria). As a result, when the display system attempts to present therecords on a display screen for subsequent pages, various recordsreferred to in the original search may be missing, causing visual dataloss or duplication. In some cases, the user may miss a record goingfrom one page to the next due to the deletion of a record on aparticular recovered page. In other cases, the system may becomeconfused as to where to start a new display page based on missingrecords that were in the original returned list of records. In stillanother case, the display system may present the same record on multiplepages based on the addition of new records to the database. None ofthese situations is desirable in a review system in which it isimportant for the reviewer to view and sign off on each and every recordin the list, as is the case with exception records in an exceptionrecord log for an order, as presented by the application 128.

FIGS. 9A and 9B illustrate the problem discussed above in a typicalbrowser based display interface that displays records as returned from asearch of records stored in a database, wherein records may be added toor removed from or have parameters thereof changed in the databaseduring the display activities. In particular, FIG. 9A illustrates a listof relevant records 700 returned from a search of a database at a timeT1 (including records R1-RN), wherein the records R1-RN may be all ofthe records for an order, or may be some ordered list of records basedon some other search criteria, such as all of the open records for anorder, all of the records of a particular severity, etc. In any event,the display system (e.g., the browser at the user interface) may, at afirst time T₁, receive the list 700, access the first seven records inthe list 700 and present these seven records in a display screen 704 onthe user interface as a first page of records. Thus, the display screen704 includes records R1-R7 as the first page of records from the search.The display system may, at a later time T₂, such as when the user asksfor the next page of records, access the database to obtain a list ofthe relevant records. Assuming no changes have been made to the recordsin the database, the same record list 700 will be returned at the timeT₂ and the display system will simply access and display the set ofrecords found in the second set of seven positions on the list(resulting in records R8-R14) as a second page of records in the display708. This operation, which is illustrated in FIG. 9A, works fine if theordered list of records 700 from the database remains static from timeT₁ to time T₂.

However, if a record is removed from the list of relevant records (e.g.,one or more records has a parameter thereof changed that keeps therecord from being found in the search of records) between the time T₁that the first page 704 is presented and the time T₂ that the secondpage 708 is presented, then the display system may inadvertently skipthe display of a record. FIG. 9B illustrates an example in which therecord R4 is removed from (or falls off of) the search list after thetime T₁ at which the first page 704 has been presented in the displaybut before the time T₂ at which the second page 708 is presented. Inthis case, the browser of the display system obtains and displays thefirst seven records R1-R7 in page one 704 based on the list 700 as it isfound in the database of FIG. 9A at time T₁. However, when the brownerof the display system goes to access the records for the second page 708in FIG. 9B, the browser simply accesses and uses the second set of sevenrecords in the returned list 710, i.e., the records in positions 8-14,in the list 710 of FIG. 9B. Because, at this time, the record R4 hasbeen removed (as it may have been closed and so removed or dropped fromthe list of relevant records), the display system displays recordsR9-R15 as the second page of records in the display 708 because recordR8, which was originally in the eighth position in the list 700 of FIG.9A when the first page was displayed, is now in the seventh position inthe list 710 of FIG. 9B due to the removal of record R4 between the timeT₁ and T₂. As such, the record R8 is not shown in either of the first orsecond pages 704 or 708 of the display of FIG. 9B, and so is missed bythe reviewer. Of course, a similar situation occurs when a record isadded to the list or database during the paging process, but in thiscase, one or more records may be duplicated or presented in consecutivepages due to the addition of a record causing a particular record thatwas originally in a position associated with one page to become locatedin a position associated with a different page at a later time.

This situation is disadvantageous when a reviewer is scrolling throughpages of exception records which have parameters that can change or inwhich new records can be added because it leads to situations in whichrelevant records are skipped in the display or in which relevant recordsare duplicated in the different pages of the display.

The quality review application 128 described herein, however, may use adifferent paging technique to determine which records to present invarious different pages of displays, and this new paging techniquereduces or eliminates the display of duplicate and/or missing recordswhen going between different pages. In particular, the quality reviewapplication 128 does not use fixed or preset locations or recordpositions in the list of records returned from the database to performpaging, but instead uses a dynamic paging algorithm that marks one ormore records, such as a first record or a last record or both a firstand a last record in the most recently displayed page, and then usesthat marker or anchor to find the set of records to display as part ofthe next page of the display. In this manner, if any records are addedto or are deleted from the relevant list of records after a page isdisplayed, the set of records displayed in the next page will be therecords in the list that are adjacent to one of the last displayedrecords (e.g., the first or the last record of the previous page) at thetime that the new page is loaded.

FIGS. 10A and 10B illustrate the operation of the new paging algorithmor technique used by the quality review interface application 128. Inthis case the lists of relevant records 700 and 710 of FIGS. 10A and 10Bas returned from the database searches at times T₁ and T₂ include thesame sets of relevant records as illustrated in FIGS. 9A and 9B,respectively. As illustrated in FIG. 10A, the interface application 128presents a first page 704 as the first seven records in the display butmarks the last or bottom record (R7) displayed in the first page 704with an anchor (referred to as Anchor1_(bot)) indicating the last orbottom record in the currently displayed page. The application 128 mayalso mark the first or top record (R1) in the display 704 with a topanchor (referred to herein as Anchor1_(top)) indicating the top or firstrecord in the currently displayed page. Then, when the application 128loads the next page of records, page 2, the application 128 searches thereturned list of records for the bottom anchor for page 1(Anchor1_(bot)) without regard to the position in the returned list 700or 710 at which this record is found. The application 128 then uses thenext seven records in the list 700 immediately after the record markedwith the bottom anchor of page 1, Anchor1_(bot), for the list of recordsto display in page 2. The application 128 may also then remove theanchor Anchor1_(bot) but may mark or store additional anchors for thenext page of records (i.e., Anchor2_(top) and Anchor2_(bot)) to mark thetop and bottom records displayed in page 2 of the display 708. Theapplication 128 then uses the record marked with Anchor2_(bot) todetermine which records to display in the next page (page 3) when theuser scrolls down in the list of page 2 or uses the record marked withthe Anchor2_(t)op to determine which records to display in a previouspage (e.g., if the user scrolls up in the list of records in page 2 togo back to page 1). As will be understood, this paging technique placesanchors or markers on records or stores anchors or markers indicatingrecords in various positions of the current display page, and uses theseanchors to determine which records in the returned set of records to usefor the first (or last) record of the next page, without regard to theactual position of records in the returned list. As such, records canmove up and down in positions within the database or returned list 700between the display of different pages without upsetting the pagingdisplay in the manner illustrated in FIGS. 9A and 9B.

As an example, FIG. 10A illustrates the operation of the use of anchorswhen no changes are made to the database between the times T₁ and T₂,resulting in the presentation of records R1-R7 in the first page 704 andin records R8-R14 in the second page 708. FIG. 10B illustrates theoperation of the use of the anchors within the list of records 710 whenthese anchors are used to perform paging at a time T₁ in which thereturned record list is the list 700 of FIG. 10A and a time T₂ in whichthe returned record list is the list 710 of FIG. 10B. In particular, thedisplay 704 for page 1 includes the records R1-R7 based on the state ofthe record list 700 in the database of FIG. 10A at time T₁ when page 1was created. However, the application 128 upon loading page 1 marked therecords R1 with the anchor Anchor1_(top) and marked the record R7 withthe anchor Anchor1_(bot). Next, at the time T₂, when the displayapplication 128 obtains the list of records 710 (which has now changedas record R4 is no longer in the list) to display page 2, theapplication 128 searches the returned list 710 for the record havingbeen marked as the Anchor1_(bot) record and upon finding this record inthe list 710, simply loads and displays the next seven records (in thiscase records R8-R14) as the page 2 display 708, despite the fact thatrecords R8-R14 are in the seventh through thirteenth positions in thelist 710. Of course, the application 128 can mark any number of anchorsper page, but will generally have two anchors per page to identify thetop and bottom records in the current page, and will then load therecords adjacent to or next to those anchors when loading subsequentpages. The use of two anchors enables the application 128 to scroll upand down in pages in a manner that eliminates or reduces missing recordsin the display or duplicating records in different pages when the statesof the records in the list change (such a record being added to orremoved from the list).

The application 128 can use any marking technique, such as storing anindication of the record(s) that is/are at the top and bottom anchorpositions in a separate anchor variable (such as in the browser orbrowser device) while a particular page is being displayed, actuallystoring a marker in the database associated with a record that iscurrently in an anchor position in the currently displayed page ofrecords, storing one or more of the records in the current page as themarker, placing a temporary marker in the database immediately before orafter a marked record, etc. Additionally, the marker or anchor can bestored in the application 128, a browser used by the application 128,the database in which the records are stored, etc. Moreover, theapplication 128 moves or changes the anchor positions or markers as newpages are accessed and displayed. Still further, the application 128 mayuse any value as the anchor for a record. For example, the application128 may use a parameter of the record at which the anchor is located asthe anchor, such as the time/date stamp of the record, etc. In somecases, the anchor for a record may be based on or indicate a searchparameter of the record or some combination of search parameters, or maybe some other unique value of the record, such as a record name,identification number, etc. Likewise, in some cases, the recordassociated with the marker may be a record that drops off the relevantsearch list. In this case, the application 128, upon not finding theanchor record in the new list (when loading a new page) may change theanchor to the record in the currently displayed page that is adjacent tothe now missing anchor record (e.g., the record in the currentlydisplayed page immediately above or preceding the bottom anchor or therecord in the currently displayed page immediately below or followingthe top anchor) and then use the new anchor to determine the set ofrecords in the returned list to present in the new display page.

Thus, the paging algorithm used by the quality review interfaceapplication 128 operates better than past paging systems in that thisnew system downloads and presents records on a new display screenstarting from the last record displayed on the previous page or screen,regardless of the positions of the records in the returned list. Thatis, instead of presenting a new display page associated with theposition of records in the original list of recovered records, thesystem 128 accesses the database for the records that currently exist inthe new list immediately after the last record on the currentlydisplayed page (when paging down the list), thereby assuring that eachtime a new set of records is displayed on the screen, the first newrecord displayed is the record in the new search list (710) thatimmediately follows the last record that was displayed in the previouspage from the previous search (700). This display system is moreaccurate as it helps to assure that records are not displayed out oforder, that records are not duplicated in multiple display pages, andthat records are not missed in the review process in which the user isscrolling through various pages of records over a long period of timeduring which changes are being made to the records in the database.Moreover, the review application 128 is more efficient, as it only needsto access the database for the number of new records that will fit on anew display page as the user is scrolling through records, while stillassuring that all of the relevant records are accessed as the userperforms the scrolling process.

It will be understood that the quality review management applicationsand the batch execution engines, server applications, plug-ins, etc.described herein can be used and implemented within any desired processplant environment, and may be used in any process plant control systemusing any desired type of process plant control communication protocol.While the applications and routines described herein are preferablyimplemented in software stored in, for example, a server, a workstation,a handheld device or other computer, these routines may alternatively oradditionally be implemented in hardware, firmware, application specificintegrated circuits, programmable logic circuits, etc., as desired. Ifimplemented in software, the routines or applications may be stored inany computer readable memory such as on a magnetic disk, a laser disk,an EPROM or EEPROM, solid state or other storage medium, in a RAM or ROMof a computer, handheld device, controller, field device, etc. Likewise,this software may be delivered to a user or a device via any known ordesired delivery method including, for example, over a communicationchannel such as a telephone line, the Internet, on a transportablemedium, such as a computer-readable disk, etc.

While the present invention has been described with reference tospecific examples, which are intended to be illustrative only and not tobe limiting of the invention, it will be apparent to those of ordinaryskill in the art that changes, additions or deletions may be made to thedisclosed embodiments without departing from the spirit and scope of theinvention.

1. A quality review system for use in monitoring the operation of aprocess, comprising: a rules database that stores a plurality of rules,wherein each of the plurality of rules includes logic that identifies aset of conditions associated with an exception within the process; oneor more data sources configured to collect process operational datawithin the process during operation of the process and configured tosend the collected process operational data in one or more datamessages, wherein the process operational data includes process dataused in one or more of the rules to analyze an exception and includesprocess metadata identifying one or more process operational conditionswhen collected; an exception engine that processes the process datawithin one or more data messages from the data sources using the rulesin the rules database to determine if an exception exists as defined byany of the plurality of rules based on the process data within the oneor more data messages, wherein the exception engine, upon identifying anexception based on one of the rules, creates an exception record for thedetermined exception and stores the exception record in an exceptionrecord database, and wherein the exception engine stores the collectedprocess metadata associated with the process operational data thatincluded the process data that resulted in the exception in addition tothe exception record; and a review interface that enables a user toreview exceptions as identified by the exception engine and as stored asthe exception records in an exception record database, wherein thereview interface accesses the exception record database, presentsinformation regarding one or more identified exceptions in the exceptionrecords to a user via a user interface and provides the user with theprocess metadata stored for the exception records via the userinterface.
 2. The quality review system of claim 1, wherein the one ormore data sources collect the process metadata for a set of process dataat the same time as the process data is collected.
 3. The quality reviewsystem of claim 1, wherein the exception engine sends an instruction toone of the data sources to collect the process metadata when theexception engine detects an exception in process data sent from the oneof the data sources.
 4. The quality review system of claim 1, whereinthe process metadata comprises process environmental data.
 5. Thequality review system of claim 1, wherein the process metadata comprisesone or more process variable values or process states.
 6. The qualityreview system of claim 1, wherein the process metadata comprises aprocess snapshot including predetermined process operational data usefulto a reviewer in performing exception review.
 7. The quality reviewsystem of claim 1, wherein the one or more data sources includes a workflow application that controls the operation of the process to implementdifferent stages of the process.
 8. The quality review system of claim1, wherein the one or more data sources includes a batch executiveapplication that controls the operation of a batch process to implementdifferent batch stages of the batch process.
 9. The quality reviewsystem of claim 1, wherein the one or more data sources includes a batchhistorian or a process historian coupled to the process.
 10. The qualityreview system of claim 1, wherein the process data includes one or moreof batch status data, batch parameter data, batch process measurementdata, batch progress data, and batch procedural model state data. 11.The quality review system of claim 1, wherein the process data includesone or more of an indication of a batch order being implemented,materials and processes associated with a batch order, a batch recipe ora batch procedural model being implemented.
 12. The quality reviewsystem of claim 1, wherein the process data includes one or more ofprocess parameter data, batch state data, batch state change data, batchalarms or batch alerts.
 13. The quality review system of claim 1,wherein the process data includes one or more indications of batchprocedure starting and stopping times or events or of batch proceduralmodel state changes.
 14. The quality review system of claim 1, whereinthe process metadata comprises process data sent to another processdatabase including one or more of a batch log file, a process controlhistorian, a process equipment historian or a batch historian.
 15. Thequality review system of claim 1, wherein the process metadata comprisesone or more of process variable values, batch procedural model states,recipe information, an order name, materials for an order, process flowsfor an order, process equipment to be used in an order, work flows to beapplied to an order or a batch procedural model used in an order. 16.The quality review system of claim 1, wherein the process metadatacomprises data that indicates the operation of the process at the timeof the exception.
 17. The quality review system of claim 1, wherein theprocess metadata comprises data batch state information, processparameter values as measured or determined from the process, processequipment information, or alarm or alert information from processequipment.
 18. A quality review system for use in monitoring theoperation of a process, comprising: one or more data sources configuredto collect process operational data within the process during operationof the process; an exception detection system coupled to the one or moredata sources, including; a rules database that stores a plurality ofrules, wherein each of the plurality of rules includes logic definingone or more exceptions and indications of process data to be applied tothe logic to determine if one or more exceptions exist based on theprocess data, and a definition of a set of process metadata associatedwith the one or more exceptions; a communication interfacecommunicatively coupled to the one or more data sources, thecommunication interface configured to receive process data from the oneor more data sources at different times during operation of the processand configured to obtain the process metadata associated with the one ormore exceptions; and an exception engine that processes the process datafrom the one or more data sources using the logic associated with theplurality of rules in the rules database to determine if an exceptionexists as defined by any of the plurality of rules on a set a processdata; wherein the exception engine, upon identifying an exception basedon one of the plurality of rules, creates an exception record for thedetermined exception and stores the exception record in an exceptionrecord database, and wherein the exception engine stores the processmetadata for the exception as part of the exception record; and a reviewinterface that enables a user to review exceptions stored as theexception records in an exception record database, wherein the reviewinterface accesses the exception record database, presents informationto a user via a user interface regarding one or more identifiedexceptions and provides the user via the user interface with at leastsome of the process metadata stored for the exception record.
 19. Thequality review system of claim 18, wherein exception engine obtains theprocess metadata from the same data source as the process data.
 20. Thequality review system of claim 19, wherein the communication interfaceis configured to receive the process metadata at the same time as theprocess data.
 21. The quality review system of claim 19, wherein theexception engine requests the process metadata for a determinedexception after identifying the determined exception based on receivedprocess data.
 22. The quality review system of claim 18, wherein theexception engine obtains the process metadata from a different datasource as the process data.
 23. The quality review system of claim 22,wherein the exception engine requests the process metadata via thecommunication interface for a determined exception after identifying thedetermined exception based on received process data.
 24. The qualityreview system of claim 22, wherein the exception engine receives theprocess metadata along with a set of process data prior to analyzing theprocess data with one of the rules.
 25. The quality review system ofclaim 18, wherein the one or more data sources includes a work flowapplication that controls the operation of the process to implementdifferent stages of the process.
 26. The quality review system of claim18, wherein the one or more data sources includes a batch executiveapplication that controls the operation of a batch process to implementdifferent batch stages of the batch process.
 27. The quality reviewsystem of claim 18, wherein the one or more data sources includes abatch historian or a process historian coupled to the process.
 28. Thequality review system of claim 18, wherein the process data includes oneor more of batch status data, batch parameter data, batch processmeasurement data, batch progress data, and batch procedural model statedata.
 29. The quality review system of claim 18, wherein the processdata includes one or more of process parameter data, batch state data,batch state change data, batch alarms and batch alerts.
 30. The qualityreview system of claim 18, wherein the process metadata comprisesprocess data stored in another process storage device including one ormore of a batch log file, a process control historian, processequipment, or a batch historian.
 31. The quality review system of claim18, wherein the process metadata comprises one or more of processvariable values, batch procedural model states, recipe information, anorder name, materials for an order, process flows for an order, processequipment to be used in an order, work flows to be applied to an orderor a batch procedural model used for an order.
 32. The quality reviewsystem of claim 18, wherein the process metadata comprises data thatindicates the operation of the process at the time of the exception. 33.The quality review system of claim 18, wherein the communicationinterface is configured to receive the process metadata along with theprocess data from a data source.
 34. The quality review system of claim18, wherein the communication interface is configured to receive theprocess metadata separately from the process data.
 35. The qualityreview system of claim 18, wherein the exception engine processes theprocess metadata prior to storing the process metadata.
 36. The qualityreview system of claim 35, wherein the exception engine process theprocess metadata by reformatting the process metadata or converting theprocess metadata to different units.
 37. The quality review system ofclaim 18, wherein different ones of the rules specify different processmetadata for the exceptions defined by the different rules.
 38. A methodof monitoring a process, comprising: storing a plurality of rules,wherein each of the plurality of rules includes logic defining one ormore exceptions related to the operation of a process and indications ofprocess data to be applied to the logic to determine if one or moreexceptions exist based on the process data, and a definition of a set ofprocess metadata associated with the one or more exceptions; obtaining,via a communication network, process data from one or more data sourceswithin the process, at different times during operation of the process;obtaining, via a communication network, process metadata associated withthe one or more exceptions; processing the process data from the one ormore data sources using the logic associated with the plurality of rulesin the rules database to determine if an exception exists as defined byany of the plurality of rules based on the process data; uponidentifying an exception based on one of the plurality of rules,creating an exception record for the determined exception, storing theexception record in an exception record database, and storing theprocess metadata for the exception as associated with the exceptionrecord in the exception record database; and enabling a user, via a userinterface device, to review the exceptions stored as the exceptionrecords in the exception record database, including accessing theexception record database via a communication network, presentinginformation to a user via the user interface regarding one or moreaccessed exceptions and providing the user via the user interface withat least some of the process metadata stored for the accessed exception.39. The method of claim 38, wherein obtaining the process data includesobtaining the process data from a first data source and whereinobtaining the process metadata includes obtaining the process metadatafrom a second and different data source than the first data source. 40.The method of claim 38, wherein obtaining the process metadata includesobtaining the process metadata at the same time as obtaining the processdata.
 41. The method of claim 38, wherein obtaining the process metadatafor an exception includes obtaining the process metadata for theexception after determining the existence of the exception.
 42. Themethod of claim 38, wherein obtaining the process metadata for anexception includes obtaining the process metadata for the exceptionbefore determining the existence of the exception.
 43. The method ofclaim 38, wherein obtaining the process metadata for an exceptionincludes requesting the process metadata from a data source afterdetermining the existence of the exception based on a set of processdata.
 44. The method of claim 38, wherein obtaining the process dataincludes obtaining the process data from a work flow application thatcontrols the operation of the process to implement different stages ofthe process or from a batch executive application that controls theoperation of the batch process to implement different batch stages ofthe batch process.
 45. The method of claim 38, wherein obtaining theprocess metadata includes obtaining the process metadata from one ormore of a batch historian coupled to the process or a process controlhistorian coupled to the process or a control system coupled to aprocess.
 46. The method of claim 38, wherein obtaining the process dataincludes obtaining one or more of batch status data, batch parameterdata, batch process measurement data, batch progress data, batchprocedural model state data, batch state data, batch state change data,batch alarms or batch alerts.
 47. The method of claim 38, whereinobtaining the process metadata includes obtaining process operationaldata that indicates the operation of the process at the time of theexception.
 48. The method of claim 38, further including processing theprocess metadata prior to storing the process metadata by reformattingthe process metadata or converting the process metadata to differentunits. 49.-97. (canceled)